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ABSTRACT 


The  existing  component  protocols,  as  weU  as  new  protocols  introduced  at  mntime 
into  NPSNET- V  are  written  in  their  native  programming  language.  As  a  result,  they 
require  authoring  and  compihng  by  a  trained  programmer.  The  long  time  frame  required 
to  change  or  introduce  new  protocols  into  NPSNET- V,  a  dynamically  extensible  virtual 
environment,  detracts  from  the  dynamicism  of  the  virtual  environment.  Networking 
optimization  thresholds  to  support  NPSNET- V  needed  to  be  determined  to  ensure  that  the 
networking  is  performed  efficiently,  and  system  resources  to  other  systems,  such  as 
graphics  rendering,  are  maximized. 

This  thesis  implements  component  protocols  described  using  Extensible  Markup 
Eanguage  (XME)  into  NPSNET- V.  These  protocols  are  created  with  different  fidelity 
resolutions  for  each  protocol,  which  can  be  swapped  at  runtime  based  on  the  network 
state.  Network  testing  was  performed  to  find  the  ideal  maximum  packet  rates  based  on 
the  impact  on  CPU  utihzation  and  packet  loss.  By  using  XME,  non- programmers  can 
edit  protocols  for  inclusion  in  a  simulation  at  mntime. 

Important  contributions  include  adding  protocols  to  NPSNET- V  with  high- 
resolution  and  low- resolution  versions,  described  by  XME  documents.  Basic  network 
optimization  is  added  to  NPSNET- V  to  take  advantage  of  the  protocols’  resolution 
switching  ability.  The  network  testing  revealed  a  linear  correlation  between  the  packet 
sending  rate  and  CPU  utihzation,  and  a  polynomial  correlation  between  the  packet 
sending  rate  and  percentage  packet  loss. 
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1.  INTRODUCTION 


A.  BACKGROUND 

This  thesis  investigates  how  the  Extensible  Markup  Language  (XML)  can  be  used 
to  describe  application- specific  networking  protocols  for  use  in  the  NPSNET- V  Virtual 
Environment.  Specifically,  it  describes  design  of  the  NPS  Dynamic -Behavior- Protocol 
(DBP)  protocols,  which  are  multicast  /  unicast  capable  and  can  be  added  at  runtime  to  the 
distributed  operating  environment.  With  XML- described  packet  payloads  for  these 
protocols,  supporting  configuration  documents  can  concisely  and  clearly  describe 
different  variations  of  these  protocols  and  can  also  enable  switching  between  them  at 
mntime. 

Protocols  described  by  XML-based  DBP  documents  can  improve  network 
performance  for  large-scale  networked  virtual  environments,  since  they  can  be  tailored  to 
best  support  the  requirements  for  a  particular  environment.  These  improvements  can  be 
made  rapidly  and  adaptively  at  mntime.  Lurthermore,  protocols  described  in  XML 
instead  of  an  imperative  programming  language  (such  as  Java  or  C-H-)  can  be  modified 
by  an  adept  nonprogrammer  or  even  software  agents,  instead  of  requiring  tedious 
debugging  and  recompilation  by  extensively  trained  computer  programmers. 

B.  MOTIVATION 

NPSNET- V  is  a  research  project  to  investigate  dynamically  extensible,  large-scale 
virtual  environments,  including  protocols  that  can  be  introduced  into  the  environment  at 
run-time.  A  limitation  of  current  systems  is  that  present-day  networking  protocols  can’t 
be  altered  without  rewriting  and  recompiling  source  code,  then  stopping  and  restarting 
the  system.  Such  constraints  on  protocol  development  prevent  proper  composabihty. 
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testing,  monitoring  and  thus  generally  detracts  from  the  NPSNET- V  goal  of  runtime 
extensibility. 

In  contrast,  a  DBP  implementation  that  can  mn,  test,  compare  and  improve 
continuously  is  expected  to  enhance  the  extensibility  of  networked  virtual  worlds,  as  well 
as  adaptively  optimize  network  performance.  A  DBP  implementation  can  further  enable 
computer- driven  mntime  optimization,  thus  providing  a  stmcture  to  make  network 
optimization  experiments  easier  to  conduct. 

C.  OBJECTIVES 

The  goal  of  this  thesis  is  to  create  DBP  protocols  that  support  communication 
between  entities  whose  prototypes  are  mntime- created,  for  use  in  the  NPSNET- V 
Research  Project.  These  network  protocols  wiU  facilitate  exchanging  state  information 
between  objects  in  the  network  and  can  be  written  in  XME  to  facilitate  flexibility,  ease- 
of-use  to  the  end  user,  and  rapid  creation  at  mntime.  These  protocols  will  support 
network  optimization  by  being  able  to  switch  between  different  source  documents  that 
describe  network  protocols  with  different  resolutions,  again  adaptively  at  mntime. 

In  NPSNET- V,  a  variety  of  software  components  including  network  protocols  can 
be  dynamically  loaded.  This  thesis  examines  adding  DBP  protocols  that  can  be  loaded  at 
mntime  in  the  same  manner  as  the  pre-existing  networking  protocols  written  in  Java. 

These  DBP  protocols  will  initially  have  the  same  semantics,  or  functionality,  as  the 
existing  protocols  that  are  described  in  Java.  By  changing  the  syntax  of  the  XME  source 
documents,  we  can  affect  changes  in  both  the  syntax  and  the  semantics  of  the  protocol  at 
mntime. 
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All  networking  protocols  are  uploaded  to  a  server,  and  a  pointer  to  a  protocol’s 
location  is  posted  to  a  LDAP  server.  When  a  participating  machine  first  encounters  an 
unknown  protocol,  it  downloads  the  corresponding  Java  byte  code  associated  with  that 
protocol  from  the  server  pointed  to  by  the  LDAP  server. 

The  network  message-format  descriptions  for  DBP  entity  communications  are 
initially  written  in  XML  and  posted  to  a  web  server.  This  byte  code  contains  a  URL  that 
points  to  an  XML  description  of  the  packet  format.  The  Java  byte  code  parses  the  XML 
file  to  discover  the  names  and  positions  of  the  fields  in  the  packet.  The  Java  protocol 
code  then  uses  this  information  to  parse  fields  and  retrieve  data  from  the  packet. 

If  changes  need  to  be  made  to  the  format  of  a  packet,  then  fields  can  be  added, 
removed  or  modified  in  the  XML  packet  description  and  the  new  description  posted  to  a 
web  server.  Based  on  the  new  description,  different  collections  of  data  can  be  passed  in 
the  network  packets.  Since  the  packet  layouts  are  written  in  XML,  protocols  can  be 
quickly  distributed  to  participating  hosts  and  written,  posted  and  incorporated  during 
execution  of  a  simulation.  Writing  XML  documents,  which  describe  packet  contents 
does  not  require  a  programmer,  an  approach  that  supports  and  enhances  the  dynamicism 
and  authorabihty  of  NPSNET- V.  XML  documents  are  similar  to  HTML  in  many 
respects  and  can  be  created  or  modified  with  a  text  editor.  Thus  an  XML  document 
describing  a  protocol  can  be  quickly  generated  this  way  and  incorporated  into  a 
simulation  at  mntime. 

These  XML- described  protocols  can  be  implemented  in  a  manner  that  supports 
extensibihty  since  the  payload  characteristics  of  protocols  can  be  easily  changed  at 
runtime  to  adapt  to  specific  requirements,  such  as  varying  network  load.  If  a  new 
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protocol  definition  is  created,  the  XML  document  is  parsed  by  an  XML  parsing  utility, 
and  the  new  protocol  description  is  included  in  the  mnning  process.  This  capabihty  to 
rapidly  create  and  switch  between  protocols  enables  performing  dynamic  network 
optimization,  in  ways  that  are  tuned  by  the  diverse  needs  of  the  application. 

To  demonstrate  the  effectiveness  of  these  XML- described  protocols,  example 
protocols  are  each  constmcted  with  one  XML  document  supporting  a  high- resolution 
packet  payload  and  another  document  describing  a  low- resolution  packet  format.  In 
support  of  this  demonstration  a  single  network  optimization  is  implemented  that  takes 
advantage  of  this  dynamic  protocol- switching  capabihty.  This  networking  optimization 
includes  maintaining  information  about  the  ongoing  state  of  the  network,  and  also  has  the 
abihty  to  adjust  protocols  on  demand  for  global  optimization.  Furthermore,  experimental 
tests  are  conducted  to  determine  networking  points  of  failure  to  determine  when  the 
protocol  switching  is  best  performed.  The  two  metrics  leading  to  possible  failure 
conditions  that  are  examined  here  are  CPU  utihzation  and  packet  loss.  Summarizing,  the 
thesis  objectives  are  straightforward  and  summarized  in  Figure  1. 


■  Implement  XML-Described  Protocols 

■  Create  High  and  Low  Resolutions 

■  Implement  Network  Monitoring 

■  Test  Networking  Points  of  Failure 


Figure  1.  Thesis  Objectives 
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D.  THESIS  ORGANIZATION 


The  chapters  of  this  thesis  are  organized  as  follows.  Chapter  n  provides  the 
background  for  this  thesis,  including  an  overview  of  subjects  considered  in  this  thesis  and 
related  work  necessary  for  understanding  context  of  the  project.  Chapter  in  presents  an 
NPSNET- V  overview  and  a  discussion  of  networking  in  NPSNET- V.  Chapter  IV 
introduces  the  strategy  used  to  implement  the  DBF  protocols,  to  implement  a  network 
monitor,  and  to  perform  the  network  testing.  Chapter  V  provides  the  results  and  analysis 
of  data  collection  and  testing,  then  discusses  tradeoffs  that  must  be  made  to  optimize  the 
protocols.  Chapter  VI  presents  thesis  conclusions  and  provides  recommendations  for 
future  work. 
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n.  BACKGROUND  AND  RELATED  WORK 


A.  INTRODUCTION 

Networked  virtual  environments  comprise  an  active  and  contemporary  research 
topic  that  is  continuing  to  develop  and  improve.  Like  most  other  topics  in  Computer 
Science,  efforts  in  this  area  build  on  the  progress  already  made. 

Design  patterns  have  been  pubhshed  that  provide  solutions  to  common  software- 
design  challenges.  Standard  procedures  have  also  been  developed  to  constmct  network 
testing  plans.  New  technologies  have  been  developed,  such  as  XML,  which  provide 
opportunities  to  apply  new  solutions  to  old  challenges.  Concurrent  and  recent  work  in 
the  same  area  impacts  design  considerations,  which  must  consider  interoperabihty.  This 
chapter  presents  a  variety  of  background  material  that  directly  influences  this  thesis. 

B.  DESIGN  PATTERNS 

Each  pattern  describes  a  problem  which  occurs  over  and  over  again  in  our 
environment,  and  then  describes  the  core  of  the  solution  to  that  problem, 
in  such  a  way  that  you  can  use  this  solution  a  million  times  over, 
without  ever  doing  it  the  same  way  twice.  (Alexander,  77) 

I.  Design  Patterns  Motivation 

Design  patterns  provide  a  common  strategy  for  solving  complex  problems.  By 
naming  these  patterns,  programmers  gain  a  common  vocabulary  by  which  to  discuss 
them.  Patterns  focus  on  specific  object-oriented  design  challenges.  Individual  patterns 
indicate  when  they  apply,  what  impact  their  use  has  on  a  project,  and  what  the 
consequences  of  their  use  are.  Patterns  identify  classes  (and  /  or  interfaces),  class 
instances,  roles,  collaborations,  and  responsibihties  (Gamma,  95). 
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Several  design  patterns  are  used  in  NPSNET- V.  The  most  important  patterns  in 
this  thesis  include  the  singleton,  observer,  and  model  /  view  /  controller  patterns. 

2.  Singleton  Pattern 

The  singleton  pattern  ensures  that  the  class  following  the  pattern  has  only  one 
instance,  and  that  there  is  a  global  means  of  accessing  that  instance  (Gamma,  95).  The 
singleton  pattern  is  usually  used  for  a  class  controUing  a  centrally  managed  resource 
(Grand,  98). 

In  a  Java  implementation,  the  singleton  class  has  a  static  variable  referring  to  the 
single  instance  of  the  class.  The  class  provides  access  to  this  instance  with  a  static 
method,  which  returns  a  reference  to  this  instance.  All  of  the  class’s  constmctors  are 
private,  to  prevent  instantiating  another  instance  of  the  class  (Grand,  98). 

3.  Observer  Pattern 

The  observer  pattern  defines  “. . .  a  one-to-many  dependency  between  objects  so 
that  when  one  object  changes  state,  all  its  dependents  are  notified  and  updated 
automatically”  (Gamma,  95).  This  pattern  uses  subjects  and  observers,  with  a  subject 
able  to  have  many  observers.  When  the  subject  experiences  a  change  in  state,  it  notifies 
its  observers,  who  in  turn  query  the  subject  for  what  the  changes  are  (Gamma,  95). 

In  a  Java  implementation,  the  subject  usually  passes  a  self- reference  as  a 
parameter  to  the  observer.  This  process  generally  uses  an  interface  for  the  method  call,  to 
enable  mn-time  registration  of  observers.  The  subject  also  provides  access  to  its  state 
attributes  for  the  observer  to  act  on  the  changes  (Grand,  98). 
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4.  Model  /  View  /  Controller  (MVC)  Pattern 

The  Model  /  View  /  Controller  (MVC)  pattern  was  originally  a  combination  of 
classes  designed  to  build  user  interfaces  in  Smalltalk- 80.  The  model  object  is  the 
application  object  that  contains  persistent  state  variables,  the  view  object  is  the  graphical 
representation  of  the  model,  and  the  controller  object  defines  the  model’s  reaction  to  user 
input.  By  loosely  coupling  these  three  components,  users  can  have  multiple  views  for  an 
object,  and  also  change  a  view  to  better  reflect  the  state  of  the  model.  Likewise,  there  can 
be  different  means  of  user  input.  Following  the  MVC  pattern  enables  each  component  to 
make  changes  based  on  information  from  another  component,  without  have  to  know  the 
inner  workings  of  the  other  two  components  (Gamma,  95). 

C.  NETWORK  MONITORING 

I.  Network  Performance  Evaluations 

Network  performance  evaluations  are  used  to  determine  how  well  a  system  is 
performing,  and  whether  any  improvements  are  necessary.  The  following  points  in 
Figure  2  are  from  the  book  “The  Art  of  Computer  Systems  Performance  Analysis”  (Jain, 
91)  and  outhne  the  steps  in  performing  such  a  study. 


•  State  the  goals  of  the  study  and  define  the  system  boundaries 

•  List  system  services  and  possible  outcomes 

•  Select  performance  metrics 

•  List  system  and  workload  parameters 

•  Select  factors  and  their  values 

•  Select  evaluation  techniques 

•  Select  the  workload 

•  Design  the  experiments 

•  Analyze  and  interpret  the  data 

•  Present  the  results.  Start  over,  if  necessary 


Figure  2.  Network  Performance  Evaluation  Steps  (Jain,  91) 
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2.  Network  Evaluation  Techniques 

The  three  evaluation  techniques  used  by  this  thesis  to  evaluate  networks  are 
analytical  modeling,  simulation  and  measurement.  Analytical  evaluation  is  best  used 
when  time  is  short  and  resources  are  low.  Analytical  evaluation  is  usually  performed 
mathematically  and  does  not  include  any  data  collection.  Simulation  evaluation  involves 
building  a  model  of  the  network  being  tested  and  collecting  data.  Measurement 
evaluation  is  performed  when  gathering  actual  data  from  the  network  being  tested.  Since 
testing  is  susceptible  to  errors,  any  network  evaluation  of  one  type  needs  to  be  verified  by 
performing  an  evaluation  of  another  type  (Jain,  91). 

This  thesis  uses  measurement  evaluation  through  network  testing.  The  metrics 
collected  focus  on  the  impact  that  packet  sending  rates  have  on  CPU  utihzation  and 
packet  loss.  Performance  thresholds  are  then  determined  during  this  testing.  This  test 
implementation  involves  reporting  the  network  state  to  the  Area  of  Interest  Manager 
(AOIM).  The  thresholds  are  then  vahdated  during  a  simulation  of  a  virtual  environment 
miming  on  top  of  NPSNET- V. 

D.  EXTENSIBLE  MARKUP  LANGUAGE  (XML) 

Extensible  Markup  Language  (XML)  is  a  meta- language  used  to  define 
stmctured-data  documents  for  other  languages.  XML  looks  similar  to  HTML,  but  is  very 
different  and  much  more  powerful.  Unhke  Hypertext  Markup  Language  (HTML),  XML 
allows  users  to  define  their  own  tags.  These  tags  may  also  describe  content  semantics 
and  are  not  simply  limited  to  formatting  as  in  HTML  (Harold,  99).  XML  provides  a 
universal  meta- markup  language  that  can  be  used  to  describe  data,  including 
configuration  data  used  in  a  program.  An  XML  document  can  be  parsed  at  mntime  and 
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the  contents  loaded  into  the  running  process.  The  data  contained  within  the  document 
can  be  as  routine  as  stored  configuration  parameters,  or  more  complex  such  as 
descriptions  of  components  to  be  created  and  included  in  the  current  process,  or  even 
scripting  code  written  using  independent  computer  languages. 

E.  TEAPOT  WORLD 

Teapot  World  was  created  as  a  simple  application  in  which  to  test  the  foundation 
protocols  of  NPSNET- V.  The  foundation  protocols  are  five  hghtweight  protocols  that 
contain  entity  state  information  of  varying  complexities  such  as  position,  angular 
acceleration,  and  animation  sequence  start  times.  The  foundation  protocols  are  included 
in  NPSNET- V  and  a  developer  can  use  them  when  creating  their  entities,  instead  of 
having  to  create  unique  protocols.  Teapot  World  also  allows  testing  of  the  DBP 
protocols,  which  have  the  same  functionahty  as  the  foundation  protocols. 

The  Teapot  World  application  mns  on  the  NPSNET- V  architecture  enabhng 
manipulation  of  teapots  in  a  Java  3D  (Sun,  01)  window.  The  model  is  an  object,  which 
inherits  from  the  NPSNET- V  entity  class  and  has  a  robust  set  of  attributes  organized  into 
hghtweight  Protocol  Data  Units  (PDUs)  for  use  in  a  3-dimensional  (3D)  worldspace.  The 
teapot  view  is  imported  from  the  Virtual  Reahty  Modeling  Eanguage  (VRME)  into  Java 
3D.  The  controller  is  user  input  from  both  the  keyboard  and  mouse. 

Teapot  World  provides  a  basehne  virtual  environment  that  is  suitable  for  testing 
protocols.  Teapot  World  testing  is  performed  both  with  two  or  more  applications  on  the 
same  machine  and  with  apphcations  mnning  between  two  or  more  machines.  By 
manipulating  the  teapot  in  the  process  in  which  it  was  created  (also  known  as  the  master 
entity)  with  the  keyboard  and  mouse,  the  copy  viewed  in  another  process  (also  known  as 
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the  ghost  view)  can  be  examined  visually  for  proper  behavior.  The  ghost  copy  can  be 
compared  directly  with  the  master  entity  to  check  for  the  same  ahgnment  and  rotation 
speeds  as  well  as  checking  whether  the  animations  mn  smoothly  on  the  ghost  side. 

Because  Teapot  World  is  a  simple  environment,  consisting  only  of  one  teapot,  it 
is  perfect  for  testing  protocols  since  other  variables  that  are  present  in  a  more  comphcated 
environment  can  be  eliminated.  An  even  simpler  version  of  Teapot  World  used  for 
network  testing  has  no  view  component  to  the  model,  so  that  no  processor  time  is  needed 
for  rendering  graphics.  This  minimalist  version  enables  further  isolating  the  networking 
aspects  of  NPSNET- V  using  the  Empty  Entity,  and  allows  sending  packets  at  a  rate 
which  tests  the  limits  of  network  capacity. 

F.  RELATED  WORK  -  AREA  OF  INTEREST  MANAGEMENT  (AOIM) 

The  NPSNET- V  AOIM  scheme  is  the  thesis  topic  of  Navy  Eieutenant  Michael  S. 
Wathen  (Wathen,  01).  NPSNET- V  uses  Area  of  Interest  Management  (AOIM)  to 
stmcture  network  traffic.  A  major  goal  of  the  AOIM  manager  is  to  limit  network  traffic 
to  only  entities  of  interest  to  the  apphcation.  Entities  that  are  grouped  toother  on  the 
same  geographic  area,  and  receive  each  other’s  messages  are  considered  to  be  in  the  same 
zone.  These  zones  are  based  on  geographic  proximity  and  the  number  of  entities  that  can 
share  information  based  on  system  and  network  load.  As  the  population  in  an 
environment  increases,  the  number  of  zones  increases  and  vice  versa.  A  procedure 
whereby  the  zones  spht  into  smaller  zones  and  the  components  are  redistributed  into 
these  new  zones  is  known  as  subdivision.  The  NPSNET- V  AOIM  procedures  are 
dynamic,  and  the  AOIM  zones  can  be  modified  at  mntime. 
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Dividing  and  combining  AOIM  zones  is  costly  due  to  computation  cost  and 
communications  delays,  and  so  may  not  always  be  an  ideal  solution  to  optimize  the 
number  of  participants  in  a  region.  Without  information  other  than  the  number  of  entities 
in  a  zone,  the  AOIM  manager  is  only  able  to  make  zone  modification  decisions  based  on 
simple  high  and  low  thresholds  for  the  number  of  participants  in  a  networked  virtual 
environment.  Further  feedback  is  needed  for  effective  large-scale  optimization. 

A  network- monitoring  implementation  can  provide  network- state  information  to 
the  AOIM  manager.  If  a  high  number  of  entities  are  in  the  same  zone,  but  are  not 
generating  many  networking  packets,  the  AOIM  manager  is  now  informed  of  this  fact 
and  may  decide  to  not  subdivide  the  zone.  Conversely,  on  the  other  end  of  the  spectmm, 
if  a  smaller  number  of  entities  are  in  a  zone  but  the  network  is  being  overwhelmed,  the 
AOIM  manager  can  subdivide  the  zone  to  reduce  the  network  load.  The  AOIM  manager 
can  look  at  the  load  on  each  channel  as  well,  to  make  smarter  decisions  of  how  to 
distribute  the  entities  into  zones  in  a  virtual  environment.  This  process  happens 
dynamically  at  mntime.  AOIM  is  a  continuous  task  since  users  are  anticipated  to 
constantly  join  and  exit  the  environment,  and  also  expected  to  cross  zone  boundaries 
fiiequently. 

With  a  DBF  network  implementation,  the  AOIM  manager  has  a  further  option  in 
optimizing  the  distribution  of  entities  in  zones.  DBF  packets  can  have  their  packet 
resolutions  changed  rapidly,  and  at  mntime.  The  network  monitoring  implementation 
informs  the  AOIM  manager  of  the  payload  resolution  of  network  packets,  currently 
implemented  as  high  or  low.  The  AOIM  manager  may  then  choose  to  reduce  or  increase 
resolution  of  state  information  in  these  packets.  A  reduction  in  resolution  reduces  the 
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size  of  the  PDUs,  reducing  the  bandwidth  used  by  the  application  and  thereby  providing  a 
network  protocol  solution. 

G.  VIRTUAL  REALITY  TRANSFER  PROTOCOL  (VRTP) 

Virtual  Reahty  Transfer  Protocol  (VRTP)  is  a  networking  protocol  research 
project  intended  to  extend  http  and  provide  support  for  Large  Scale  Virtual  Environments 
(LSVEs).  ESVEs  are  primarily  conshucted  as  either  peer-to-peer  or  server-based.  VRTP 
provides  a  solution  that  enables  both  type  of  architectural  designs,  or  even  a  hybrid 
approach,  to  be  implemented.  VRTP  can  serve  as  the  sole  protocol  needed  to  support  a 
ESVE.  VRTP  will  combine  many  existing  dissimilar  protocols  to  provide  this  solution 
(Bmtzman,  97).  Network  monitoring,  such  as  the  techniques  presented  in  this  thesis,  is 
expected  to  be  as  important  as  chent- server  and  peer-to-peer  support. 

1.  Breakthroughs  and  Bottlenecks 

Virtual  environments  continuously  push  the  limit  for  computational  complexity 
and  networking  availabihty.  As  technology  continues  to  improve  in  these  areas  and 
remove  bottlenecks,  virtual  environment  design  makes  a  leap  forward  until  it  hits  the  next 
bottleneck.  VRTP  implementations  are  expected  to  provide  the  breakthroughs  needed  to 
overcome  the  networking  protocol  bottleneck  (Bmtzman,  77). 

2.  Real-time  Transport  Protocol 

Real-time  Transport  Protocol  (RTP)  supports  apphcations  where  speed  is  of  high 
importance.  RTP  adds  quality  of  service  and  synchronization  to  existing  transport 
protocols.  RTP  is  ideal  to  support  LDP -based  applications  such  as  streaming  audio  and 
video.  Since  speed  is  of  vital  importance  in  ESVEs,  RTP  will  further  contribute  to  the 
networking  protocol  efforts  in  an  ESVE  (Afonso,  99). 
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3.  NPSNET-V 


NPS  has  advocated  and  supported  persistent  online  virtual  worlds  for  years.  A 
large-scale,  persistent  virtual  world  must  have  mntime-extensibihty,  scalabUity,  and 
composabihty.  One  of  the  main  challenges  to  achieving  these  goals  is  networking  issues. 
NPSNET-V  and  DBP  wil  continue  to  develop  as  VRTP  components.  Together  these 
provide  a  new  protocol  at  the  application  layer  to  accomphsh  a  variety  of  interdependent 
objectives  and  overcome  diverse  networking  bottlenecks  (Bmtzman,  97). 

H.  SUMMARY 

This  chapter  provides  an  overview  of  design  patterns,  basic  network  testing 
procedures,  XML,  and  related  work  on  the  NPSNET-V  project. 

Using  existing  design  patterns  not  only  ensures  that  a  good  software- design 
approach  is  followed,  but  also  provides  a  common  terminology  with  which  to  discuss 
design  and  implementation  issues.  The  network- testing  considerations  presented  in  this 
chapter  provides  a  checkhst  with  which  to  evaluate  a  thorough  network- testing  design. 
XML  is  a  new  and  exciting  technology  that  makes  it  possible  to  implement  new  solutions 
to  many  challenges,  such  as  mntime- modifiable  protocol  specifications.  Teapot  World  is 
a  simple  environment  in  which  to  measure  metrics  and  test  networking  thresholds,  while 
limiting  interference  from  many  of  the  other  dynamic  variables  in  a  complex  virtual 
environment.  Concurrent  and  related  work,  especially  in  AOIM,  significantly  impacts  on 
network  optimization,  since  AOIM  controls  the  channel  allocations  and  is  concurrently 
attempting  runtime  optimization.  VRTP  is  a  framework  for  integrating  the  variety  of 
client,  server,  peer-to-peer  and  network  monitoring  protocols  needed  to  provide  essential 
network  serveices  for  LSVEs. 


15 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


16 


m.  NPSNET-V 


A.  INTRODUCTION 

This  chapter  provides  an  overview  of  the  elements  of  NPSNET-V  that  affeet  both 
eomponent  protoeols  and  network  optimization.  The  key  eomponents  affeeting  the 
relationships  between  entities  and  protoeols  are  presented,  along  with  flow  of  eontrol  of 
the  network  monitoring  and  optimization  algorithm.  Protoeols  ineluded  with  NPSNET-V 
are  speeifieally  diseussed.  The  goal  to  optimize  NPSNET-V  networking  may  differ 
somewhat  from  general  network  optimization,  so  this  ehapter  provides  additional 
baekground  that  illustrates  how  design  strategies  were  derived  and  implemented. 

B.  MODEL /VIEW /CONTROLLER 

The  Model  /  View  /  Controller  (MVC)  pattern  is  eommonly  used  in  objeet- 
oiiented  programming  for  virtual  environments.  The  Model  objeet  deseiibes  how  an 
objeet  interacts  with  its  environment,  eontaining  the  state  variables  and  physies  model  of 
the  objeet.  The  model  eontains  eiitieal  attributes  and  eomputational  procedures  such  as 
entity’s  position,  veloeity,  and  collision- avoidance  algorithms.  Most  networking 
protocols  in  NPSNET-V  directly  implement  the  model  component. 

The  View  objeet  provides  the  one  or  more  visual  depletions  of  an  entity.  One 
useful  reason  for  having  multiple- view  objeets  is  to  enable  multiple  resolutions  of  an 
entity,  or  even  multiple  graphies  formats.  NPSNET-V  eurrently  supports  both  Java  3D 
and  VRME/X3D  eomponent  views. 

The  Controller  objeet  enables  a  eonsistent  way  to  ehange  values  in  the  model 
objeet.  The  Controller  objeet  ean  aeeept  input  to  ehange  the  model  from  many  sourees 
ineluding  user  input,  network  traffic  and  multi- agent  input. 
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C.  ENTITIES 

1.  Entity  Masters 

Entity  masters  inherit  from  the  entity  class  and  describe  the  authoritative  instance 
of  an  entity.  Typically  there  exists  only  one  entity  master  on  a  machine  controlled  by  a 
user.  In  addition,  there  may  be  one  or  more  entity  masters,  known  as  agent  masters, 
controlled  by  an  autonomous  agent.  All  other  instances  of  the  same  entity  are  a  ghost 
copy  of  that  entity.  Entity  masters  include  the  singleton  model  class  and  typically  also 
link  a  controller  and  a  view. 

2.  Entity  Ghosts 

Every  other  instance  of  an  entity  that  is  not  the  master  is  an  entity  ghost.  Often 
each  host  in  a  distributed  exercise  will  contain  one  or  more  masters,  which  interact  with 
ghost  copies  of  other  entities  from  other  machines  and  any  agent  masters  located  on  that 
machine.  The  ghost  copies  are  local  copies  of  remote  masters  and  thus  their  state 
information  may  not  necessarily  be  correct.  Messages  from  the  entity  masters  are  sent  to 
ghosts,  who  interpret  the  messages  to  update  and  extrapolate  state  values  in  the  local 
copies  of  the  entity’s  ghosts. 


Entity 


Eigure  3.  Inheritance  hierarchies  for  abstract  Entity  interface  and  instantiable  Entity 
Master  and  Entity  Ghost  interfaces 
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3. 


LDAP  Server 


All  NPSNET- V  entity  class  definitions  exist  on  a  web  server.  If  a  user  wishes  to 
create  a  new  class  of  entity,  they  must  either  host  a  web  server  or  arrange  to  have  the 
class  definitions  placed  on  an  accessible  web  server. 

When  a  virtual  world  attempts  to  load  a  new  entity,  it  doesn’t  necessarily  have  the 
class  definition  or  know  which  web  server  it  is  stored  on.  When  an  unknown  entity  is 
encountered  for  the  first  time,  a  well-known  Lightweight  Directory  Access  Protocol 
(LDAP)  server  is  queried,  which  provides  a  URL  to  the  server  that  stores  the  entity  class 
information.  An  LDAP  server  is  a  hghtweight  server  that  is  similar  in  function  to  a 
DNS  server.  An  LDAP  server  maintains  a  table  of  addresses  of  where  to  find 
information.  In  NPSNET- V,  the  LDAP  servers  maintain  addresses  of  where  to  find 
copies  of  code  (McGregor,  01).  Replicated  LDAP  servers  can  cache  replicated  copies  of 
such  code  and  content,  which  thereby  increases  rehabihty,  accessibihty  and  scalabihty. 

In  the  long  term,  VRTP- capable  hosts  participating  in  LSVEs  are  expected  to 
provide  individual  serving  capabihties. 

4.  Networking  Overview 

Entities  in  the  NPSNET- V  virtual  environment  need  a  means  of  communicating 
with  each  other.  They  accomphsh  this  many-to-many  message  passing  through 
application- specific  protocols.  Each  entity  has  one  or  more  protocols  that  report  updates 
to  the  state  information  of  that  entity.  The  master  instance  of  the  entity  understands  how 
to  generate  Protocol  Data  Units  (PDUs)  describing  changes  in  entity  state.  The  ghost 
instances  of  this  entity  receive  such  messages  and  understands  how  to  decode  the  PDU  to 
make  the  appropriate,  corresponding  changes  to  the  ghost. 
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The  network  flow  begins  when  the  controller  object  is  notified  of  a  change  to  the 
entity’s  internal  state.  The  protocol  generates  a  PDU  with  the  appropriate  data  and  passes 
this  PDU  to  the  Area  of  Interest  Manager  (AOIM).  The  AOIM  decides  where  to  send  the 
PDU.  The  Entity  Dispatcher  is  a  singleton  packet  handler  that  directs  aU  traffic  flow  of 
PDUs  coming  into  and  leaving  the  NPSNET- V  application.  The  PDU  message  is  then 
passed  to  the  appropriate  Channel  object  where  it  is  written  to  the  appropriate  multicast 
(or  unicast)  network  address/port  combination  corresponding  to  that  AOI  area  of  interest. 
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Figure  4.  Event- sequence  diagram  for  sending  a  network  packet. 
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Figure  5.  Event- sequence  diagram  for  receiving  a  network  packet. 

The  packet  is  received  on  channels  of  remote  machines  that  are  hstening  to  traffic 
from  that  entity.  The  Entity  Dispatcher  inspects  the  payload  header  to  determine  the 
ghost  entity  that  the  message  is  intended  for,  and  then  forwards  it  to  the  entity.  The  ghost 
entity  then  decodes  the  message  using  the  appropriate  protocol,  and  applies  the  changes 
plus  extrapolations  to  the  ghost  entity’s  state. 

D.  DYNAMIC  BEHAVIOR  PROTOCOL  (DBP) 

Java  applications  routinely  use  object  serialization  for  networking 
communications.  Unfortunately,  this  Java- specific  approach  requires  the  network 
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packets  to  be  in  very  specific  (and  perhaps  non- portable)  binary  formats.  Using  object 
serialization,  the  objects  being  passed  and  restored  must  utihze  identical  serialization  in 
all  respects.  Sometimes  conflicts  can  arise  from  simple,  subtle  differences  such  as 
serializing  two  identical  objects  using  different  compilers  or  different  versions. 
Additionally,  using  serialized  packet  formats  detracts  from  the  interoperabihty  of 
NPSNET- V,  since  these  cannot  be  made  to  match  existing  non- Java  packet  formats. 

Dynamic  Behavior  Protocol  (DBP)  uses  Extensible  Markup  Eanguage  (XME)  to 
describe  packet  formats  and  fields.  Using  DBP,  we  can  create  packets  with  specific 
layouts  without  relying  on  Java- specific  object  serialization.  DBP  protocols  use  a  binary 
format  on  the  network  and  can  be  created  and  modified  at  mntime.  Once  an  XME 
protocol  created  this  way  has  been  distributed  and  parsed,  a  local  entity  knows  how  to 
read  and  write  the  PDU-packet  format. 

E.  ENTITY  DISPATCHER 

The  entity  dispatcher  is  a  singleton  in  NPSNET- V  and  is  the  central  hub  for 
message  routing  on  each  host  machine.  The  entity  dispatcher  maintains  a  hst  of  all 
entities  in  the  system  and  controls  the  channel  manager,  which  in  turn  controls  each  of 
the  network  channels  used  to  send  and  receive  network  traffic.  As  shown  in  figure  5, 
incoming  messages  are  passed  from  the  channels  to  the  entity  dispatcher.  The  entity 
dispatcher  determines  which  entity  is  addressed  by  the  message  and  then  forwards  it. 
Outgoing  messages  follow  the  same  flow  in  reverse. 

F.  PROTOCOLS 

1.  Protocols  in  NPSNET-V 

Entities  register  their  protocols  with  the  entity  dispatcher.  Each  protocol  is 

assigned  a  unique  Globally  Unique  Identifier  (QUID)  for  improved  performance.  When 
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a  message  encoded  using  an  unknown  protocol  is  received,  the  entity  dynamically  loads 
the  protocol  component  associated  with  that  GUID,  and  packet  payloads  corresponding  to 
that  protocol  are  thereafter  understood  by  the  owning  entity. 

2.  NPSNET-V  Foundation  Protocols 

Five  foundation  protocols  are  provided  by  the  NPSNET-V  architecture.  They  are 
the  transform,  inertial,  animation,  articulation  and  acceleration  protocols  (McGregor,  01). 
Each  of  the  five  protocols  inherits  from  the  protocol  base  class.  The  transform  protocol 
provides  spatial  position,  orientation  and  scale  operations.  The  inertial  protocol  conveys 
linear  and  angular  velocity.  The  animation  protocol  allows  simple  animations,  the 
articulation  protocol  passes  data  for  articulation  of  additional  joints,  and  the  acceleration 
protocol  adds  data  for  linear  and  angular  acceleration. 

The  five  foundation  protocols  provide  a  robust,  lightweight  network- 
communicaitons  package  to  communicate  entity  state  changes.  Since  the  protocols  are 
included  in  NPSNET-V,  any  apphcation  mnning  on  top  of  NPSNET-V  can  use  these 
protocols  for  its  entities.  In  the  event  that  these  protocols  do  not  meet  the  requirements 
for  an  application,  additional  specialized  protocols  can  be  loaded  dynamically. 

3.  DBP  Protocols 

The  DBP  protocols  are  a  separate  protocol  package  included  with  NPSNET-V. 
The  DBP  protocols  include  examples  that  are  identical  to  the  foundation  protocols  in 
functionahty,  each  having  the  same  names  and  field  descriptions. 

DBP  protocols  are  defined  by  one  or  more  XME  documents  that  describe  the 
layout  of  the  protocols.  Even  though  the  field  descriptions  are  the  same  as  for  the 
foundation  protocols,  the  data  types  may  be  different  in  order  to  experiment  with 
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performance  optimization.  As  an  example,  a  foundation  protocol  field  defined  as  having 
type  double  may  be  described  in  the  corresponding  DBP  protocol  as  a  float.  Once  a 
protocol- defining  XML  document  has  been  parsed,  the  protocol  is  ready  to  send  and 
receive  packets  without  having  to  parse  the  definition  document  again  later.  Different 
versions  of  a  protocol  can  be  described  by  different  XML  documents,  and  thus  a  protocol 
can  be  redefined,  communicated,  reparsed  and  thus  updated  at  mntime. 

G.  NETWORK  CHANNELS 

1.  Channels 

NPSNET- V  establishes  AOIM- organized  channels,  each  of  which  encapsulates  a 
socket  for  network  communications.  The  AOIM  determines  which  channel  a  protocol 
packet  is  sent  on.  Typically,  aU  entities  within  the  same  AOIM  zone  have  their  protocols 
send  updates  on  the  same  channel,  corresponding  to  a  particular  geographic  area. 

Limiting  network  traffic  within  a  zone  to  a  multicast  channel  enables  individual  host 
machines  to  disregard  packets  that  are  not  of  interest  to  active  entities  on  the  local 
machine.  This  culling  of  unwanted  network  packets  via  multicast- hardware  capabihties 
improves  performance  and  enables  effective  scalabihty  to  much  higher  aggregate  traffic 
levels. 

2.  Channel  Manager 

The  channel  manager  is  a  singleton  created  by  the  entity  dispatcher.  The  channel 
manager  keeps  track  of  channels  that  have  been  created. 

H.  SUMMARY 

This  chapter  provided  an  overview  of  the  elements  of  NPSNET- V  that  affect 
protocol  design  and  network  optimization.  NPSNET- V  follows  the  Model  /  View  / 
Controller  (MVC)  paradigm,  which  enhances  the  extensibility  of  the  design  architecture. 


24 


The  entities  in  a  virtual  environment  each  have  two  main  components:  the  master  entity 
resides  on  the  owning  machine  and  maintains  the  authoritative  state  information,  while 
the  ghost  copies  reside  on  every  other  machine  that  has  knowledge  of  the  entity.  The 
DBF  protocols  use  XML  documents  that  are  parsed  to  define  the  data  types  and  initial 
values.  This  flexibihty  can  be  exploited  to  enable  different  resolutions  for  each  protocol 
and  dynamic  mn-time  updates.  The  AOIM  scheme  uses  channels  to  divide  the 
networking  traffic  among  different  multicast  (or  unicast)  address/port  combinations  for 
hardware  culling  of  unwanted  network  packets  and  scalable  traffic  handling. 
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IV.  DESIGN  OF  EXPERIMENTS 


A.  INTRODUCTION 

This  chapter  discusses  the  experimental  approaches  used  to  demonstrate  and 
evaluate  the  main  goals  of  this  thesis.  There  are  three  separate  efforts.  The  first  effort  is 
creating  XML- based  protocols.  The  second  is  constmcting  a  network  monitor.  The  third 
effort  is  determining  the  networking  points  of  failure  that  can  occur  while  mnning  a 
virtual  environment,  and  thus  establish  default  thresholds  for  protocol  switching. 

B.  DBF  PROTOCOLS 

The  basic  protocols  already  included  with  NPSNET- V  are  the  five  foundation 
protocols.  These  implemented  protocols  make  an  excellent  starting  point  for 
implementation  via  the  DBF  protocols,  thereby  enabling  experimental  comparisons.  Five 
DBF  protocols  were  created  based  on  the  foundation  protocols:  transform,  inertial, 
acceleration,  animation,  and  articulation.  Since  these  DBP  protocols  mirror  the 
foundation  protocols  in  functionahty,  they  can  be  compared  directly  to  verify  functional 
correctness  and  also  to  test  for  any  inherent  advantages  provided  by  DBP  fiexibihty. 

The  entities  that  the  DBP  protocols  are  to  interface  with  in  NPSNET- V  are 
written  in  Java.  They  have  coded  expectations  for  parameters  that  can  be  received  and 
sent.  For  this  reason,  the  DBP  protocols  each  require  that  the  supporting  XML 
documents  define  these  same  parameters.  Although  this  may  limit  the  abihty  of  the  XML 
documents  to  describe  parameter  definitions  for  use  in  the  protocols,  the  data  types  for 
these  definitions  can  be  changed  to  meet  changing  requirements. 

To  take  advantage  of  the  dynamic  abihties  of  the  DBP  protocols,  and  to  simply 
achieve  useful  implementations,  each  protocol  is  described  with  both  a  high- resolution 
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and  a  low- resolution  XML  document  definition.  To  accomplish  this,  each  value  normahy 
defined  as  a  64- bit  double  in  the  normal  high- resolution  version  has  a  counterpart  defined 
as  a  32-bit  float  in  the  low- resolution  version.  Additionahy,  each  64-bit  long  data  type  in 
the  high- resolution  protocols  has  a  corresponding  32- bit  integer  datatype  definition  in  the 
low- resolution  protocols.  When  a  packet  is  sent,  the  appropriate  data  types  are  written  to 
a  byte  stream  based  upon  which  protocol  resolution  the  protocol  has  been  directed  to  use. 
On  the  receiving  end  of  a  packet,  the  protocol  tests  each  mutable  value  that  arrives  to  see 
which  data  type  is  being  used.  This  implementation  ahows  great  fiexibihty  when 
specifying  varying  protocol  resolutions. 

To  quantitatively  test  the  correct  behavior  of  the  DBF  protocols,  a  network 
monitor  and  a  visual  display  were  created.  The  network  monitor  counts  the  number  of 
bytes  sent  and  received,  and  the  display  creates  a  graph  that  shows  this  information.  Two 
identical  entities  are  created  that  use  the  same  DBF  protocols.  The  entities  both  send 
packets  at  the  same  rate,  implemented  with  a  heartbeat  timer.  They  are  compared  at  the 
same  time,  one  with  protocol  set  to  high  and  the  other  to  low  resolution.  Next,  the  same 
test  is  performed  comparing  the  DBF  protocols  to  their  corresponding  Foundation 
protocols. 

C.  NETWORK  MONITOR 

A  network  monitor  was  created  to  gather  statistical  data  about  network 
performance  for  use  in  optimization.  The  networking  metrics  selected  for  measurement 
are  packets  sent  and  received,  and  bytes  sent  and  received.  These  two  metrics  allow 
measuring  the  data  rate  in  packets- per- second,  as  well  as  the  bandwidth  used  by  an 
application.  Data  rate  and  bandwidth  are  two  measurable  indicators  that  can  be  used  to 
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predict  network  load.  Knowing  this  information  can  be  used  for  determining  whether  to 
switch  protocol  resolutions  at  mntime  and  take  advantage  of  the  DBP  protocol  flexibihty. 

Whenever  packets  are  sent  or  received  through  the  entity  dispatcher,  the  network 
monitor  is  notified  of  the  number  of  bytes  and  number  of  packets  sent  or  received. 
Following  the  observer  pattern,  an  apphcation  interested  in  the  network  data  instantiates  a 
network  monitor  and  queries  it  at  the  desired  interval. 

The  data  collection  point  selected  is  at  the  Entity  Dispatcher.  The  Entity 
Dispatcher  is  a  singleton,  which  ensures  no  double  reporting  of  data,  and  all  network 
traffic  flows  through  it,  which  ensures  that  all  packets  are  counted.  The  Network  Monitor 
was  initially  designed  as  a  singleton,  but  was  later  changed  to  a  private  data  member  of 
the  singleton  Entity  Dispatcher.  A  redundant  data  collection  system  has  been 
implemented  with  data  collection  for  every  channel,  but  this  is  currently  disabled  and  not 
needed.  Data  collection  in  the  Entity  Dispatcher  can  be  turned  on  or  off  at  the  discretion 
of  the  programmer. 

The  Network  Monitor  collects  data  for  every  packet  sent  or  received.  Summary 
data  is  returned  to  those  subscribed  listeners  that  request  it.  The  returned  network- 
monitoring  information  contains  eight  values: 

•  average  number  of  packets  received 

•  average  number  of  bytes  received 

•  average  number  of  packets  sent 

•  average  number  of  bytes  sent 

•  number  of  packets  received  since  the  last  report 
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•  number  of  bytes  received  since  the  last  report 

•  number  of  packets  sent  since  the  last  report 

•  number  of  bytes  sent  since  the  last  report 

The  Network  Monitor  has  an  adjustable  time  duration  for  data- collection  buffers. 
The  averages  computed  are  averaged  over  this  time  interval.  Data  is  dropped  from  the 
buffer  list  when  older  than  the  specified  duration.  The  resulting  averaging  process  is 
similar  to  the  shding- window  procedure  used  in  TCP  connections  (Peterson,  00). 

The  Network  Monitor  reports  the  status  of  the  network  as  quiet,  busy,  or 
thrashing  when  queried.  The  thresholds  for  when  the  network  is  considered  busy  or  quiet 
can  be  set  through  function  calls,  and  are  initiahzed  to  default  values  based  on  the 
network- testing  portion  of  this  thesis.  If  the  measured  network  state  repeatedly  crosses 
back  and  forth  across  the  high  and  low  thresholds,  then  the  network  state  can  be 
considered  thrashing.  Thresholds  for  the  number  of  times  the  state  attempts  to  switch  and 
the  time  interval  across  which  these  attempts  occur  can  both  be  set  through  the  interface 
to  the  network  monitor. 

D.  EVALUATION  STUDY 

Following  the  steps  presented  in  Chapter  n,  the  experiment  follows  the  steps 
presented  in  “The  Art  of  Computer  Systems  Performance  Analysis”  (Jain,  91): 

1.  The  goals  of  the  experiments  are: 

•  Determine  the  correlation  between  packets- per- second  and  CPU 
utilization 

•  Determine  bandwidth  utilization 
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Determine  packets-per- second  at  which  CPU  usage  is  at  10% 


•  Find  ways  in  which  packets  can  be  modified  in  order  to  optimize  network 
performance 

Since  a  machine  typically  receives  many  more  packets  than  it  sends,  the  point  of 
measurement  is  at  the  receiving  machine. 

2.  For  testing,  only  one  machine  is  the  sender,  and  the  other  the  receiver.  The 
sender  produces  packets  of  a  fixed  size  at  a  steady  rate.  The  receiver  consumes  and 
measures  the  sent  packets.  The  two  machines  are  disconnected  from  any  other  networks 
to  eliminate  any  interference  or  noise.  Both  sender  and  receiver  use  the  Empty  Protocol, 
which  passes  a  fixed- size  byte- payload. 

3.  The  metrics  selected  are  discussed  in  paragraph  F  below  and  include 
bandwidth,  packets- per- second,  and  CPU  utilization. 

4.  The  system  parameters  are  discussed  in  paragraph  G  below.  Network 
benchmark  testing  is  performed  between  two  machines  connected  by  either  a  100  Mbps 
Ethernet  connection  or  a  56K  modem  connection.  This  testing  is  performed  using  likely 
packet  sizes  at  varying  packet  rates  in  10- second  transmission  windows. 

5.  The  key  parameters  for  the  experiment  are  hsted  in  Eigure  6  and  defined  as 

follows: 

•  The  available  bandwidth  is  set  at  two  different  levels  (Ethernet 
100  Mbps  and  56K  modem). 
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•  The  packet  size  is  set  at  three  different  levels,  representing  the 
transform  high,  transform  low  and  animation  high  packet 
definitions. 

•  The  packets-per-  second  sending  rate  is  varied  at  regular  intervals. 


•  Available  Network  Bandwidth 

•  Packet  Size 

•  Packets  Per  Second 

Figure  6.  Modifiable  Experiment  Parameters 

6.  The  evaluation  techniques  are  discussed  in  paragraph  E  below  and  include 
both  simulation  and  measurement- based  network- evaluation  techniques. 

7.  The  workload  consists  of  an  empty  entity  that  transmits  byte  arrays  of  the  three 
protocol  packet  sizes  at  an  adjustable  rate. 

8.  Eor  the  experimental  design,  packets  are  sent  at  steady  rates,  over  a  range  of 
flow  rates.  Three  iterations  are  performed  for  measurements  at  each  transmission  rate. 

9.  Eor  the  data  analysis,  the  data  is  examined  to  determine  if  conclusions  can  be 
drawn  from  the  samples  taken. 

10.  Eor  the  display  presentation,  the  results  are  plotted  to  determine  the  optimal 
and  maximum  desired  packet  rates,  and  then  metrics  are  compared  against  each  other  to 
determine  if  any  correlation  exists  among  the  results. 
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E.  EVALUATION  TECHNIQUES 

1.  Simulation 

The  simulation  conducted  is  performed  with  an  empty  entity  that  transmits 
packets  of  three  tested  sizes.  The  first  size,  138  bytes,  represents  a  high-resolution 
transform  protocol  packet.  The  second  size,  74  bytes,  represents  a  low-resolution 
transform  packet.  The  third  size,  19  bytes,  represents  a  high- resolution  animation 
protocol  packet.  This  simulation  determines  how  well  the  receiving  machine  and 
transmission  media  might  handle  different  packet  flow  rates  for  these  different  packet 
sizes.  The  percent  packet  loss  and  percent  CPU  utilization  are  measured  at  the  receiving 
machine. 

2.  Measurement 

The  measurement  is  performed  after  the  results  have  been  analyzed  and 
benchmarks  are  established.  The  benchmarks  are  established  based  on  observations 
regarding  how  well  the  networking  optimization  performs  during  an  actual  simulation. 

F.  METRICS 

I.  General 

In  conducting  experiments  to  determine  the  appropriate  settings  for  the  DBP 
protocols,  three  metrics  (listed  in  Figure  8)  are  used:  bandwidth  used,  packets  per 
second,  and  CPU  usage.  The  experiments  seek  to  quantify  the  relationship  between  these 
three  metrics  and  the  proper  settings  for  the  DBP  packets  to  achieve  application-based 
optimization. 
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•  Bandwidth  Used 

•  Packets  Per  Second 

•  CPU  Utilization 


Figure  7.  Experiment  Metrics 


2.  Bandwidth 

The  definition  of  bandwidth  used  in  this  thesis  is  the  aggregate  bits-per- second 
provided  to  the  apphcation.  The  term  available  bandwidth  refers  to  the  bandwidth 
provided  by  the  physical  media  used  to  connect  the  network.  Changing  the  type  of 
connection  between  two  machines  can  change  the  maximum  bandwidth  available.  The 
two  tested  connections  are  an  Ethernet  100  Mbps  connection  and  a  56K  bps  modem 
connection.  These  two  connections  represent  the  target  100  Mbps  high  end  and  56k  bps 
low  end  of  anticipated  chent  connections  in  web- based  distributed  virtual  environments. 

3.  Packets  per  Second 

The  packets  per  second  metric  simply  measures  the  number  of  packets  sent  over  a 
one-  second  interval.  Packets  are  measured  at  that  rate  for  a  four- minute  time  period  and 
the  average  packets-per- second  value  calculated.  The  four- minute  measurement  window 
is  selected  for  two  reasons.  Eirst,  a  sufficiently  long  duration  is  needed  to  simulate 
reahstic  application  conditions.  Second,  a  surge  in  CPU  utilization  occurs  approximately 
every  3  1/2  minutes,  which  is  correUatable  and  attributed  to  Java  garbage  collection  of 
transient  data  stmctures.  Since  data  collection  must  occur  under  reahstic  conditions,  the 
measurement  time  interval  must  not  eliminate  or  avoid  this  occurrence.  The  four- minute 
data- capture  window  ensures  consistent  inclusion  of  a  single  garbage -coUection  event. 
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The  high- resolution  transform  protocol  payload  is  16  doubles,  which  equates  to 
128  bytes.  The  high- resolution  inertial  protocol  has  a  payload  of  13  doubles  and  2 
longs,  for  a  payload  size  of  120  bytes.  The  high-resolution  animation  protocol  has  a 
payload  of  1  long  and  1  byte  for  a  payload  size  of  9  bytes.  The  high- resolution 
acceleration  protocol  has  a  payload  of  6  doubles  for  a  payload  size  of  48  bytes.  The  high- 
resolution  articulation  protocol  has  a  payload  of  4  doubles  for  a  payload  size  of  32  bytes. 
Each  protocol  has  an  internal  overhead  of  10  bytes  and  NPSNET- V  prepends  a  header  of 
24  bytes. 

The  low- resolution  transform  protocol  payload  is  16  floats,  which  equates  to  64 
bytes.  The  low- resolution  inertial  protocol  has  a  payload  of  13  floats  and  2  integers,  for 
a  payload  size  of  60  bytes.  The  low- resolution  animation  protocol  has  a  payload  of  1 
integer  and  1  byte  for  a  payload  size  of  5  bytes.  The  low- resolution  acceleration  protocol 
has  a  payload  of  6  floats  for  a  payload  size  of  24  bytes.  The  low- resolution  articulation 
protocol  has  a  payload  of  4  doubles  for  a  payload  size  of  16  bytes.  Each  protocol  has  an 
internal  overhead  of  10  bytes  and  NPSNET- V  prepends  a  header  of  24  bytes. 

External  to  NPSNET- V,  each  packet  has  a  20  bytes  header  for  IP,  and  a  8  byte 
header  for  UDP.  Systems  connected  using  Ethernet  have  an  Ethernet  header  of  18  bytes 
prepended.  Systems  connected  by  modem  using  Point- to- Point  Protocol  (PPP),  have  a 
PPP  header  of  six  bytes,  and  the  IP  and  UDP  headers  are  reduced  to  a  total  of  3  bytes 
(Stevens,  94).  The  total  overhead  external  to  NPSNET- V  using  an  Ethernet  connection  is 
46  bytes,  and  using  PPP  on  a  modem  is  9  bytes. 
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Protocol 

Payload 

Total  Packet 
Size  NPSNET-V 

Total  Size 
Ethernet 

Total  Size 
Modem 

Transform  Hiah 

128 

162 

208 

173 

Transform  Low 

64 

98 

144 

109 

DSSlSOSIi^^l 

120 

154 

200 

165 

Inertial  Low 

60 

94 

140 

105 

9 

43 

89 

54 

Animation  Low 

5 

39 

85 

50 

Acceleration  Hiqh 

48 

82 

128 

93 

Acceleration  Low 

24 

58 

104 

69 

Articulation  Hiah 

32 

66 

112 

77 

Articulation  Low 

16 

50 

96 

61 

Figure  8.  DBF  Packet  Sizes 


The  most  common  type  of  packet  in  a  networked  virtual  environment  is  a  packet 
updating  a  participant’s  position,  analogous  to  the  DIS  protocol  ESPDU  (Singhal,  99). 

The  DBF  protocol  that  provides  analogous  fiinctionahty  is  the  transform  protocol.  The 
transform  protocol  is  98  bytes  in  size  at  low- resolution  and  162  bytes  at  high- resolution. 
The  transform  protocol  is  also  the  largest- sized  DBF  packet  type,  so  if  conditions  are 
tested  using  the  transform  protocol,  packets  from  the  other  protocols  will  fit  within  the 
bandwidth  footprint  tested. 

4.  CPU  Usage 

A  host  CPU  consumes  processing  power  for  each  packet  that  it  sends  and 
receives.  It  is  important  to  measure  how  much  work  the  CPU  must  do  to  process  network 
packets.  Of  further  interest  is  seeing  whether  correlations  exist  between  CPU  usage  and 
packets-per-  second. 

The  amount  of  CPU  processing  used  to  process  packets  from  the  network  needs 
be  balanced  with  other  requirements.  Keeping  the  network’s  resource  demand  low 
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provides  greater  host  resources  for  interaction  calculations,  graphics  rendering,  and  other 
tasks.  A  design  decision  was  made  by  the  NPSNET- V  Research  Group  to  keep  this 
processing  to  between  10%  and  15%  maximum  CPU  capacity.  The  target  maximum 
packet- per- second  transmission  rate  will  thus  correspond  to  the  CPU  usage  at  10%. 

G.  TESTING 

1.  Determining  Benchmarks 

For  the  DBP  protocol’s  abihty  to  switch  resolutions  to  be  useful,  such  switching 
must  occur  automatically  and  at  the  appropriate  times.  One  of  the  goals  of  testing  the 
impact  of  packet  rates  on  the  receiving  machine  is  to  determine  the  optimal  and 
maximum  packet  flow  rates.  Once  benchmarks  are  established,  the  program  can  better 
collect  data  during  execution  and  then  make  network- optimization  decisions  by 
comparing  the  collected  data  to  these  benchmarks. 

2.  Protocols 

a.  Empty  Protocol 

For  testing,  a  new  Foundation  protocol  was  created,  the  empty  protocol, 
which  merely  transmits  an  empty  packet  with  a  predetermined  byte  size.  The  entity 
master  is  on  the  sending  machine  and  the  ghost  is  on  the  receiving  machine.  The  empty 
protocol  is  used  to  gather  information  about  packets  dropped  and  CPU  usage  at  the 
receiving  machine.  This  testing  is  done  at  a  variety  of  packet  rates,  including  sending  as 
fast  as  possible  from  the  sending  machine.  The  sending  rates  are  set  based  on  spreading 
the  rates  out  to  achieve  an  even  distribution  between  zero  and  the  maximum  sending  rate. 
The  rates  are  adjusted  by  adding  intermittent  delays  to  slow  down  the  sending  rate.  This 
is  done  rather  than  sending  a  specified  number  of  packets  per  second  which  would  cause 
surging  behavior  instead  of  the  desired  even  flow  rate. 
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b.  DBF  Protocol 

The  DBF  protocols  have  high  and  low  resolution  settings.  Parsing  an 
XML  document  and  reading  in  the  appropriate  data  types  for  each  parameter  of  the 
protocol  sets  the  resolutions.  The  high- resolution  format  uses  data  types  that  are 
synonymous  with  the  foundation  protocols.  The  low- resolution  version  of  this  protocol 
degrades  64-bit  doubles  to  32-bit  floats,  and  64-bit  long  integers  to  32-bit  integers. 

To  compare  the  effects  of  these  savings  in  packet  size,  the  number  of  bytes 
transmitted  over  a  minute  at  the  high  resolution  is  compared  to  the  corresponding  number 
of  bytes  at  low  resolution.  Additionally,  these  measurements  are  compared  to 
measurements  of  the  foundation  protocols  of  the  same  type.  To  achieve  synchronization 
and  consistency,  the  protocols  transmit  periodic  “heartbeat”  packets,  and  data  is  averaged 
over  a  minute. 

3.  Test  Environment 

The  platforms  used  for  testing  are  two  Pentium  IH  1-Ghz  computers  with  256  MB 
RAM.  These  systems  use  Windows  2000  with  Service  Pack  2  as  their  operating  system. 
The  programming  language  used  is  Java’s  JDK  1.3.1  (Java,  01).  The  sending  platform 
mns  an  Apache  web  server  (Apache,  01)  and  an  LDAP  server  (Eudora,  01).  The 
receiving  machine  mns  the  network  monitor  apphcation  to  measure  CPU  usage. 

When  tests  are  mn  between  the  systems,  the  fast  connection  is  a  100  Mbps 
Ethernet  connection  using  multicast.  The  slower  connection  is  between  two  external  56k 
modems  mnning  PPP  connections  and  using  UDP  unicast  packets.  In  each  case,  the 
machines  are  isolated  on  their  own  standalone  network,  with  minimal  apphcations 
mnning  in  the  background. 
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H.  PACKET  RESOLUTIONS 

1.  DBP 

The  dynamic  behavior  protocols  can  have  their  resolution  adjusted  at  mntime. 
Merely  changing  the  XML  documents  that  describe  the  protocol  packets  can  create 
varying  resolutions.  Only  the  payload  (and  not  the  header)  of  the  packet  is  reduced. 

2.  Other  Protocols 

To  change  the  resolution  of  any  protocol  other  than  the  DBP  protocols,  a 
programmer  must  create  a  new  protocol,  which  enables  the  resolution  changes  in  the 
protocol.  This  flexibihty  is  only  possible  following  extensive  manual  programming, 
compilation,  testing  and  debugging  by  experienced  programmers. 

I.  SUMMARY 

This  chapter  discusses  the  design  of  experiments  used  to  conduct  all  three  major 
portions  of  this  thesis.  The  DBP  protocols  are  written  in  Java,  and  each  have  supporting 
XML  files  that  describe  the  data  type  definitions.  The  network  monitor  reports  the 
current  state  of  the  network  to  indicate  when  to  switch  resolutions  with  a  DBP  protocol. 
The  network  testing  is  designed  to  estabhsh  the  optimization  points  in  the  NPSNET- V 
networking  architecture,  and  identifies  where  to  set  the  network  monitor  state  thresholds. 
Extensive  parameter  analysis  and  metric  values  are  discussed. 
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V.  EXPERIMENTAL  RESULTS  AND  ANALYSIS 


A.  INTRODUCTION 

This  chapter  presents  the  results  of  the  experiments  corresponding  to  the  three 
main  objectives  of  this  thesis:  DBP  Protocol  implementation,  the  network  monitor,  and 
the  analysis  of  protocol  changes  for  network  optimization.  The  majority  of  this  chapter  is 
devoted  to  conducting  isolated  network  testing  to  quantify  the  critical  break  points  in 
CPU  utihzation  and  percent  packet  loss.  Packets-per- second  and  CPU  utilization  graphs 
are  presented  with  plotted  means  and  standard  deviations. 

B.  DBP  PROTOCOLS 

I.  Protocol  Switching 

Two  identical  entities  are  compared  to  each  other,  one  using  high  and  the  other 
low- resolution  DBP  protocols.  These  two  entities  both  used  the  transform  protocol.  The 
only  means  of  sending  packets  is  through  a  heartbeat  thread,  which  sent  a  packet  of  each 
type,  by  each  entity,  once  per  second.  The  NPSNET- V  system  network- status  utihty  was 
used  to  compare  the  two  entities  to  give  a  graphic  representation  of  the  byte  savings  when 
switching  resolutions.  The  low- resolution  only  transmitted  approximately  60%  of  the 
bytes  that  the  high- resolution  protocol  did. 

Comparing  the  DBP  transform  protocol  directly  to  the  hard  coded  foundation- 
version  transform  protocol,  shows  much  greater  savings  in  bytes  sent.  The  high- 
resolution  DBP  transform  protocol  sends  approximately  25%  of  the  number  of  bytes  as 
its  foundation  counterpart.  The  low- resolution  DBP  transform  protocol  sends  only  15% 
of  the  bytes  compared  to  the  foundation  protocol. 
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Reducing  packet  sizes  for  Ethernet  connections  does  not  yield  a  significant 
advantage.  Reducing  the  number  of  packets  sent,  however,  does  result  in  a  performance 
gain.  This  performance  gain  primarily  comes  from  reduced  processing  requirements  in 
the  variety  of  threaded  Channel,  Entity  Dispatcher,  Entity  Master  /  Ghost,  and  Protocol 
classes  that  handle  the  packet  distribution.  Eurther  performance  gains  can  be  expected 
for  ESVEs  distributed  across  Wide-Area  Networks  (WANs)  due  to  reduced  packet- 
routing  overhead  in  routers.  WAN  optimization  for  widely  distributed  ESVEs  will  be  an 
important  area  for  future  work. 

When  high  numbers  of  packets  are  being  sent  using  either  different  protocols  or 
from  different  entities,  we  can  gain  efficiency  by  combining  some  of  the  data  into 
packets.  Since  the  data  sent  in  a  virtual  environment  is  timely,  using  such  a  strategy  must 
have  an  either  /  or  condition  for  sending  data,  where  either  enough  data  exists  to  fill  a 
packet,  or  a  short  timer  has  expired.  If  packet  aggregation  were  incorporated  into 
NPSNET- V,  the  savings  result  is  4  to  6  Vi  times  fewer  packets  sent  whenever  an  entity  is 
actively  sending  packets. 


□  Bytes  /  Second 


Eigure  9.  Comparison  of  Protocols’  Bytes  Per  Second 
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Figure  10.  DBF  Transform  Protocol  Running  at  Low  and  High  Resolution 
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Figure  1 1 .  DBF  and  Foundation  Transform  Protocol  Running  at  High  Resolution 
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Figure  12.  DBF  and  Foundation  Transform  Protocol  Running  at  Low  Resolution 

2.  XML  Descriptions 

The  DBF  protocols  each  have  two  pieces:  a  general- DBF  Java  program  that 
describes  the  functionality  of  the  protocol,  and  an  XML  document  that  describes  the  data 
types  and  initial  values  for  the  protocol.  The  relationship  between  the  general- DBF  Java 
class  file  and  XML  documents  that  define  protocols  is  one-to-many.  The  first  time  each 
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XML  document  is  used  by  a  protocol,  it  must  be  parsed.  During  testing,  the  protocols 
parsed  the  required  documents  smoothly  and  without  error.  Each  XML  file  can  be  edited 
with  any  text  editor.  The  XML  documents  can  have  their  data- type  descriptions  and 
initial  values  changed  quickly  and  easily  this  way. 

C.  NETWORK  MONITOR  ANALYSIS 

Operation  of  the  network  monitor  has  been  verified  by  comparing  known  packet 
and  byte  quantities  sent  and  received  with  the  quantities  reported  by  the  network  monitor. 
The  output  graph  displayed  by  the  monitor  is  easy  to  read  and  gives  a  clear  picture  of 
bothe  current  and  ongoing  network  state. 

A  concern,  as  with  most  monitoring  utihties,  is  whether  the  load  put  on  the  system 
to  gather  networking  data  is  worth  the  information  gathered.  A  series  of  empty  protocols 
tests  were  mn  without  any  network  monitoring  actions  being  performed.  The  transform- 
high  protocol  was  selected  since  it  puts  the  greatest  load  on  the  system.  The  CPU 
utihzation  was  reported  and  compared  to  the  same  test  in  which  the  data- gathering  was 
enabled.  These  measurements  are  presented  in  figure  12.  They  show  that  approximately 
2  Vi  %  of  the  CPU  utilization  is  required  to  collect  this  data  at  the  target  10%  CPU 
Utilization. 
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CPU  utilization  -  Transform  High  Protocol  With  and  Without  Network  Monitoring 


Figure  13.  CPU  Utilization  Transform  High  -  With  and  Without  Data  Collection 
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D.  METRICS  ANALYSIS 


The  metrics  analysis  investigates  the  effects  on  CPU  load  and  packet  loss  of 
various  packet  sending  rates,  packet  sizes,  and  physical  transmission  media.  The  results 
of  this  analysis  are  used  to  determine  what,  if  any,  relationships  exist  between  these 
metrics. 

I.  Ethernet  Packet  Loss 

The  maximum  rate  that  packets  can  be  sent  was  minimally  affected  by  the  packet 
size.  The  maximum  sending  rate  was  approximately  5,600  packets- per- second.  The 
packet  loss  for  the  Ethernet  testing  was  affected  mostly  by  the  rate  at  which  the  packets 
were  sent,  and  unaffected  by  the  packet  size.  The  packet  loss  for  all  three  packet  types 
increased  exponentially  with  the  sending  rate.  The  best  fit  is  a  third- order  polynomial 
graph.  The  packet  losses  for  all  packet  types  were  between  1.5%  and  4.5%  at  the 
maximum  sending  rate. 

The  packet  loss  for  Ethernet  testing  was  also  affected  by  the  size  of  the  packets 
being  sent.  Eor  both  the  high- resolution  (138  bytes)  and  the  low- resolution  (74  bytes) 
transform  packets,  minimal  (0.1%)  packet  loss  began  at  a  sending  rate  of  800  packets- 
per- second.  Eor  the  high- resolution  animation  protocol  packet,  the  same  minimal  packet 
loss  began  at  about  1,500  packets- per- second.  At  the  maximum  sending  rate,  the  loss 
rates  were  around  4%,  2.5%  and  1.5%  for  the  transform- high,  transform- low,  and 
animation- high  protocol  packets  respectively. 
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Percent  Packet  Loss 


Packet  Loss  -  Tranform  High  (138  Byte)  Packets  Using  Ethernet  100  Mbps 


Figure  14.  Packet  Loss  Transform  High  -  Ethernet  (maximum  value  4.2%) 
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Percent  Packet  Los: 


Packet  Loss  -  Tranform  Low  (74  Byte)  Packets  Using  Ethernet  100Mbps 


Figure  15.  Packet  Loss  Transform  Low  -  Ethernet  (maximum  value  2.9%) 
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Percent  Packet  Loss 


Packet  Loss  -  Animation  High  (19  Byte)  Packets  Using  Ethernet  100  Mbps 


Figure  16.  Packet  Loss  Animation  High  -  Ethernet  (maximum  value  2.2%) 


51 


2. 


MODEM  Packet  Loss 


For  all  three  packet  sizes  and  for  various  sending  rates,  including  the  maximum 
sending  rate,  there  were  no  packets  lost  over  the  modem  connection.  The  maximum 
achieved  sending  rate  by  modem  was  94  packets-per- second,  which  is  not  sufficiently 
large  to  cause  the  receiving  CPU  to  drop  any  packets. 

The  constrained  available  bandwidth  did  not  cause  the  UDP  packets  to  drop 
during  the  send  operation  as  initially  predicted.  The  TCP/IP  stack  checks  the  socket  send 
buffer  and  if  it  is  fuU,  blocks  the  process  from  sending  more  packets.  This  happens  in  the 
sosendO  method  in  the  TCP/IP  stack.  The  modem  send-buffer  fills  quickly,  since  it  is 
constrained  by  the  slow  connection,  and  imposes  constant  delays  on  the  sending 
application.  This  happens  even  though  the  packets  are  UDP. 

3.  Ethernet  CPU  Usage 

For  Ethernet  connections,  the  load  on  the  receiving  machine’s  CPU  is  hnearly 
proportional  to  the  sending  rate  as  measured  in  packets-per- second.  The  CPU  utihzation 
percentage  is  the  same  for  aU  three  packet  types  sent.  The  maximum  CPU  utihzation  is 
approximately  60%,  at  the  highest  achieved  sending  rate  of  approximately  5,600  packets- 
per- second. 

The  lack  of  correlation  between  packet  size  and  CPU  utihzation  is  not  surprising. 
The  CPU  must  use  cycles  to  process  each  packet  that  arrives,  which  can  add  up  quickly. 
This  is  one  reason  why  Ethernet  cards  are  generahy  set  to  hsten  to  certain  ports  and  not 
be  promiscuous  (i.e.  not  hsten  to  ah  ports). 
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CPU  Percent  Utilizatioi 


CPU  Utilization  -  Transform  High  (138  Byte)  Packets  Using  Ethernet  100  Mbps 


Figure  17.  CPU  Utilization  High- ResolutionTransform  Protocol  -  Ethernet 
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CPU  Percent  Utilizatioi 


CPU  Utilization  -  Transform  Low  (74  Byte)  Packets  Using  Ethernet  100  Mbps 


Figure  18.  CPU  Utilization  Low- ResolutionTransform  Protocol  -  Ethernet 
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CPU  Percent  Utilization 


CPU  Utilization  -  Animation  High  (19  Byte)  Packets  Using  Ethernet  100  Mbps 


Figure  19.  CPU  Utilization  High- Resolution  Animation  Protocol  -  Ethernet 
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CPU  utilization  -  Transform  High  (138  Byte)  Packets  Using  MODEM 


Figure  20.  CPU  Utilization  High- Resolution  Transform  Protocol  -  Modem 

(maximum  value  7.5%) 
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CPU  utilization  -  Transform  Low  (74  Byte)  Packets  Using  MODEM 


Figure  21.  CPU  Utilization  Low- Resolution  Transform  Protocol  -  Modem 

(maximum  value  7.6%) 
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CPU  utilization  -  Animation  Protocol  (19  Byte)  Packets  Using  MODEM 


Figure  22.  CPU  Utilization  High- Resolution  Animation  Protocol  -  Modem 

(maximum  value  7.5%) 
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4.  Modem  CPU  Usage 

The  MODEM  CPU  usage  also  has  a  linear  correlation  with  the  sending  rate, 
plotted  in  Figures  20-22,  in  packets- per- second.  The  MODEM  CPU  usage,  like  the 
Ethernet  CPU  usage,  is  mostly  independent  of  the  tested  packet  sizes.  The  CPU  usage 
reaches  a  maximum  of  around  3.5%  at  the  maximum  packet  sending  rate  of  94  packets- 
per- second  (animation  high  protocol). 

5.  Ethernet  Cyclic  Behavior 

CPU  utihzation  is  observed  to  have  a  spike  approximately  every  3  Vi  minutes. 

This  occurs  only  while  the  receiving  machine  was  actually  receiving  packets  sent  by 
NPSNET- V.  The  apparent  cause  for  this  occurrence  is  Java  garbage  collection.  In  the 
case  of  low  data  rates  being  sent,  the  spike  is  pronounced,  and  with  high  data  rates  the 
CPU  utihzation  takes  on  a  sinusoidal  appearance. 

This  cychc  behavior  caused  many  measurement  inconsistencies  in  earher  tests. 
Several  unsuccessful  attempts  were  made  to  either  control  or  predict  the  garbage 
coUection.  Since  this  phenomenon  occurs  during  actual  implementation  in  a  virtual 
environment  as  weU  as  during  experimental  testing,  ah  of  the  test  mns  were  redone  and 
the  data- coUection  interval  was  increased  to  four  minutes  in  order  to  ensure  consistent 
inclusion  of  a  solitary  garbage  coUection  event.  This  strategy  ensures  more  reaUstic 
conclusions,  since  the  garbage  coUection  occurs  consistently  during  simulation  tests. 

6.  Modem  Packets  Per  Second 

The  number  of  packets  per  second  sent  by  modem  were  expected  to  be  around  30 
maximum,  not  the  observed  300.  The  high- resolution  transform  protocol  was  used  to  test 
this  surprising  initial  result  further.  The  high-resolution  packet  is  138  bytes  with  10 
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additional  bytes  prepended  by  NPSNET- V.  UDP  adds  8  bytes,  IP  20  bytes  and  PPP  18 
bytes  as  header  information.  This  results  in  a  total  of  198  bytes  for  each  packet.  If  the 
entire  56K  bps  is  utilized,  7000  bytes  can  theoretically  be  sent  across  the  wire  per  second. 
This  means  an  estimated  35  200-byte  packets  per  second  might  be  sent  for  this  test.  Thus 
the  300- packet  result  is  quite  surprising. 

Modem  compression  hardware  is  designed  to  maximize  bandwidth  capacity 
limitations.  The  headers  are  compressed,  as  is  the  payload.  The  initial  payload  consisted 
of  byte  arrays  filled  with  the  default  values  of  zero.  Next  several  byte  arrays  were 
randomly  created  with  random  values  and  the  sending  apphcation  would  switch  between 
them.  Again,  surprisingly,  this  yielded  the  same  results.  Finally,  in  another  approach, 
each  byte  array  was  uniquely  created  with  random  generation,  which  finally  resulted  in 
an  expected  maximum  sending  rate  of  30  packets-per- second.  Thus  the  expected  modem 
capacity  matched  theoretical  predictions,  and  the  demonstrated  capabihties  of  modem 
compression  on  repetitive  traffic  is  quite  impressive. 

E.  SUMMARY 

This  chapter  discusses  the  experimental  results  and  analyses  used  to  conduct  all 
three  major  portions  of  this  thesis.  The  DBF  protocols  are  written  in  Java,  and  each  have 
supporting  XML  files  that  describe  the  data  type  definitions.  The  network  monitor 
reports  the  current  state  of  the  network  to  indicate  when  to  switch  resolutions  with  a  DBF 
protocol.  The  network  testing  is  designed  to  estabhsh  the  optimization  points  in  the 
NFSNET- V  networking  architecture,  and  identifies  where  to  set  the  network  monitor 
state  thresholds. 
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VI.  CONCLUSIONS 


A.  INTRODUCTION 

This  chapter  presents  the  conclusions  from  the  experiments  performed  and 
analyses  derived  in  this  thesis.  Two  interesting  opportunities  for  future  work  are 
presented  that  can  further  enhance  the  optimization  of  virtual  environment  networking. 

B.  ANALYSIS 

I.  CPU  UtiUzation 

There  is  a  direct  correlation  between  CPU  Utilization  and  the  sending  rate  in 
packets-per-second.  For  the  (1  Ghz)  machines  used  to  conduct  the  experiments  using 
NPSNET- V,  the  relationship  on  an  Ethernet  connection  can  be  estimated  by  y  =  0.01 14x, 
where  y  is  the  CPU  percent  utihzation  (0- 100%)  and  x  is  the  number  of  packets  per 
second  sent  to  the  receiving  machine. 

Similarly  the  direct  correlation  between  CPU  Utihzation  and  packets  per  second 
sent  for  modem  NPSNET- V  connections  can  be  estimated.  The  correlation  can  be 
estimated  with:  y  =  0.025x,  where  y  is  the  CPU  Utilization  percentage  (0- 100%)  and  x  is 
the  number  of  packets  per  second  sent. 

The  initial  objective  for  CPU  utihzation  was  to  limit  the  percent  used  for 
networking  to  10%.  Eor  Ethernet  connections,  this  equates  to  a  limit  of  877  packets  of 
interest  per  second.  Eor  modem  connections,  this  is  estimated  at  400  packets  per  second, 
which  exceeds  the  maximum  achieved  rate  of  94  packets  per  second.  The  network  busy 
threshold  is  set  at  850  packets-per-second  for  ethemet  as  a  default  value,  based  on  these 
findings.  Eor  modem  connections,  this  is  estimated  at  94  packets  per  second. 
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The  low  threshold  is  set  initially  at  850  packets-per- second.  The  Network 
Monitor  recalculates  this  value  during  execution  to  reflect  the  average  value,  in  packets- 
per- second,  along  with  the  standard  deviation  of  the  mean.  Setting  the  threshold  this  way 
will  continue  to  report  the  network  state  as  busy  until  the  traffic  has  resumed  a  normal 
flow  rate.  This  will  help  prevent  thrashing  during  surges.  Further  feedback  may  be 
necessary  to  enable  proper  participation  by  modem- connected  hosts. 

2.  Packet  Loss 

The  maximum  packet  loss  observed  is  around  4%,  which  is  surprisingly  low. 
Keeping  with  the  original  requirement  of  limiting  the  CPU  utilization  for  networking  to 
10%,  the  number  of  packets  per  second  is  877  maximum  for  Ethernet  connections.  This 
results  in  an  approximately  0.1%  packet  loss.  For  modem  connections,  there  has  been  no 
observed  packet  loss.  These  findings  indicate  that  significantly  large  distributed  virtual 
environments  may  be  possible  for  modem- connected  participants. 

3.  Packet  Size 

The  packet  size  had  minimal  (if  any)  impact  on  the  tested  metrics  for  Ethernet 
connections.  For  modem  connections,  the  packet  size  affects  the  sending  rate  by  causing 
the  modem  send  buffer  to  fill  quicker  for  larger  packets.  The  CPU  utihzation  and  packet 
loss  are  mainly  affected  by  the  rate  of  packet  sending,  especially  for  Ethernet 
connections.  For  this  reason,  packet  aggregation  ought  to  be  considered  to  limit  the  total 
number  of  packets  sent  across  the  network.  Reducing  packet  rates  further  reduces  the 
possibihty  of  router  congestion. 

4.  DBP  Protocols 
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The  DBF  protocols  are  easy  to  use  and  there  were  no  problems  switching  between 
XML  documents  for  any  of  the  protocols.  Switching  between  high- resolution  and  low- 
resolution  protocols  works  effectively.  Nevertheless,  for  these  experiments  changing  the 
resolution  has  httle  impact  on  network  optimization.  Combined  with  packet  aggregation 
or  under  congestion  conditions,  being  able  to  specify  packet  sizes  with  XML  described 
documents  might  be  a  great  contribution  towards  automatic  network  optimization. 

Further  testing  on  more  heavily  utihzed  networks  will  likely  yield  further  insights. 

The  XML- described  protocols  are  easy  to  edit  at  runtime  using  any  text  editor. 
Similarly,  such  protocols  can  be  authored  or  modified  by  network- aware  software 
apphcations,  including  software  agents.  The  data  types  declared  in  the  XML  document 
must  be  supported  by  the  accompanying  Java  class  file.  Data  types  that  support  the 
existing  protocols  are  now  implemented  and  work  successfully  during  execution. 

Although  the  current  experimental  implementation  does  not  gain  much  by  reducing 
packet  sizes,  tremendous  design  and  implementation  advantages  can  be  gained  by  the 
mntime  extensibihty  offered  by  XML- described  protocols. 

C.  FUTURE  WORK 

There  are  two  principle  areas  of  future  work:  network  management  and  multi¬ 
agent  monitoring.  Both  of  these  areas  outhne  improvements  to  apphcation- based 
network  optimization. 

1.  Network  Manager 

Instead  of  implementing  a  network  management  scheme  that  simply  reacts  to 
basic  high- resolution  and  low- resolution  thresholds,  a  more  sophisticated  application- 
oriented  network  manager  might  be  implemented.  Instead  of  making  adjustments  based 
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on  single-period  observations,  such  as  an  increase  in  average  packets-per- second, 
automated  decisions  can  be  made  based  on  trends  observed  as  a  result  of  key  parameter 
combinations,  for  example  an  increase  in  packets-per- second  combined  with  out-of-order 
delivery  may  indicate  oncoming  congestion  that  demands  immediate  attention  (i.e.  better 
inferences  can  be  made  than  merely  using  a  simple  observation  of  an  increase  in  packets- 
per- second). 

The  networking  parameters  currently  monitored  are  packets-per- second  and 
bytes-per- second.  Unfortunately,  direct  measurements  of  overall  CPU  utihzation  were 
not  possible  using  native  Java  hbraries.  Nevertheless,  based  on  manual  measurements 
and  correlations  estabhshed  by  experimentation,  estimates  of  CPU  utihzation  and  packet 
loss  can  be  achieved.  There  are  also  many  other  network  parameters  that  can  be 
measured.  These  include  buffer  sizes,  out-of-order  packet  arrivals,  latency,  jitter  (i.e. 
latency  variations),  and  particular  performance  considerations  based  on  the  specific 
apphcation  being  used. 

Like  the  current  implementation,  an  advanced  network  manager  can  provide 
constantly  updated  information  to  the  Area  of  Interest  Manager  (AOIM)  about  the 
network  status.  The  AOIM  can  then  make  better- informed  optimization  decisions.  If  the 
best  solution  includes  networking  changes,  the  network  manager  is  notified  and  directed 
to  implement  it.  Such  a  methodology  can  even  occur  in  a  distributed  fashion  across  ah 
participants  in  a  distributed  virtual  environment. 

The  proposed  design  motivation  for  this  network  manager  is  the  “better,  faster, 
cheaper:  pick  any  two”  paradigm.  Better  solutions  can  include  greater  resolutions, 
fidelity  and  correctness.  Faster  solutions  include  increased  speeds  for  computation  and 
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network  transmissions.  Cheaper  solutions  include  lightweight  solutions  such  as  smaller 
payloads,  less  computationally  intense  payload  algorithms,  or  further  sacrifices  in  either 
of  the  other  two  solution  strategies.  Automating  analysis  and  optimizations  of  such 
tradeoffs  is  a  rich  area  for  future  work. 

2.  Multi-Agent  Monitor 

NPSNET- V  provides  an  architectural  framework  on  which  to  mn  a  virtual 
environment.  The  current  networking  solutions  may  not  work  with  a  future  virtual 
environment.  A  networking  monitor  created  as  part  of  a  Multi- Agent  System  might  learn 
how  to  optimize  such  a  distributed  system  and  implement  an  optimized  solution. 

Agents  have  the  abihty  to  make  adjustments  to  solution  strategies  based  on 
feedback  from  the  distributed  systems  they  are  monitoring.  An  agent  solution  is  also  able 
to  weed  through  a  high  number  of  input  parameters  and  then  determine  an  appropriate 
networking  strategy. 

The  proposed  approach  with  which  to  implement  a  multi- agent  monitor  is  to 
populate  each  system  with  an  organization  of  agents  that  gather  their  information  through 
the  Entity  Dispatcher.  These  agents  might  be  organized  as  advisors  to  a  central  agent. 
The  central  agent  can  choose  courses  of  action  based  on  the  current  priorities  and  also 
recommendations  by  its  advisor  agents.  Such  a  central  agent  (or  set  of  agents)  will  likely 
have  the  authority  to  direct  or  advise  AOIMs  as  well. 

An  experimentally  grounded  and  dynamically  scalable  approach,  similar  to  the 
monitoring  architecture  presented  in  this  thesis,  will  enable  the  creation  and  maintenance 
of  rich  and  responsive  large-scale  virtual  environments. 
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D.  CONTACT  INFORMATION 

To  obtain  an  electronic  copy  of  the  NPSNET- V  code,  contact  one  of  the  Research 
Faculty  through  the  website  at  http://www.npsnet.0rg/~npsnet/v/ 
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APPENDIX  A 


A.  INTRODUCTION 

This  appendix  provides  the  Java  and  XML  source  code  for  the  DBF  Transform 
protocol. 

B.  DBF  TRANSFORM  JAVA  SOURCE  CODE 

package  org . npsnet . v . test . dabp . dbpfoundation . dbputil ; 

import  java.io.*; 
import  java.net.*; 
import  java . util .* ; 
import  java . util .Vector .* ; 
import  javax . vecmath . *; 
import  javax .media . j 3d .* ; 
import  java . lang . * ; 

import  org . npsnet . V . sys .* ; 
import  org . npsnet . V . net .* ; 

import  org . npsnet . v . test . dabp . dbpfoundation . *; 
import  org . web3d. vrtp . dabp ; 
import  org . web3d. vrtp . datatypes . * ; 

!  -k  -k 

*  A  protocol  for  passing  information  about  <code>Transf ormable</code> 
entities . 

*  *  @author  Bill  Fischer 
*/ 

public  class  DBPTransf ormProtocol  extends  org . npsnet .v . sys . Protocol 
implements  Serializable 

{ 

j  k  k 

*  The  class's  version  string. 

*/ 

private  static  final  String  classVersion  =  "$Revision:  1.2  $ " ; 

j  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  classCodebaseString  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 

*  The  singleton  instance  of  this  class. 

*/ 

private  static  DBPTransf ormProtocol  transf ormProtocol  =  null; 

I  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  PROTO_URL  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 

*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 
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*/ 

string  hiXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/TransformP rot ocolPacket . xml" ) ; 

^  -k  -k 

*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  loXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/ Trans formP rot ocolPacket LoRes . xm 

1")  ; 

^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  hiResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (hiXmlFile)  ; 

^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  loResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (loXmlFile)  ; 

^  -k  -k 

*  Returns  this  class's  version  string. 

*/ 

public  String  getClassVersion ( )  { 

return  classVersion; 

} 

^  -k  -k 

*  Returns  this  class's  codebase. 

*/ 

public  URL  getClassCodebase ( )  { 

try  {  return  new  URL (classCodebaseString) ;  } 

catch (MalformedURLException  e)  {  return  null;  } 

} 

^  -k  -k 

*  Returns  the  singleton  instance  of  <code>Transf ormProtocol</code> . 
*/ 

public  static  DBPTransformProtocol  getinstance ( )  { 

if (transformProtocol ! =null)  return  transformProtocol ; 
else  { 

try  { 

org . npsnet . V . sys . Protocol  tmpProt  = 

get Singlet on ( "org . npsnet . v . test . dabp . dbp foundation . dbputil . DBPTransformProtocol 
", classVersion) ; 

if (tmpProt  ==  null) 

transformProtocol  =  new  DBPTransf ormProtocol ( ) ; 

else 

transformProtocol  =  (DBPTransformProtocol) tmpProt; 

} 

catch ( IDServerException  ise)  { 

System. out .println  (ise) ; 

System . exit  ( 1 ) ; 

} 

return  transformProtocol; 

} 

} 
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^  -k  -k 

*  Constructor;  takes  a  few  parameters,  which  allow  us 

*  to  operate  in  the  world. <p> 

•k 

*  Note  that  this  constructor  is  for  use  with  new  EntityMasters — 

*  We  create  a  new  entity  and  send  out  information  on  it.  The 

*  creation  of  the  entity  registers  a  new  entity  ID  and  new 

protocolIDs 

*  to  go  along  with  it . <p> 

•k 

*  @param  pEntity  entity  that  we  update 
*/ 

public  DBPTransf ormProtocol ( )  throws  IDServerException 

{ 

//  A  new  instance  requires  a  new  ID 

super ( "DBPTransf ormProtocol "  ,  true) ; 

} 

^  -k  -k 

*  Constructor.  Note  that  this  constructor  is  for  use  with 

*  things  we  have  discovered  from  the  net.  we  get  in  a  new 

*  message  with  an  existing  ID.  That  means  we  don't  have  to 

*  look  up  the  ID  on  the  IDServer.<p> 

•k 

*  @param  pID  id  of  the  protocol,  gleaned  from  network  traffic 
*/ 

public  DBPTransf ormProtocol ( long  pID)  throws  IDServerException 

{ 

super (pID,  IDCache . getIDCache ( ) . getNameForlD (pID) ) ; 

} 


^  -k  -k 

*  This  receives  a  packet  from  the  entity  and  serializes  it,  ie, 

changes 

*  all  the  data  fields  into  a  byte  array  that  we  can  send  across  the 

*  network.  ADU  is  some  nominal  superclass  from  DABP  that  subsumes 

all 

*  packets. 

*/ 

public  byte [ ]  serializeADU (Ob ject  pPacketData) 

{ 

byte  serializedData [ ]  =  null; 

ADUData  transformADU  =  null; 

transformADU  =  (ADUData) pPacketData; 

ByteArrayOutputStream  oStream  =  new  ByteArrayOutputStream ( ) ; 
DataOutputStream  dos  =  new  DataOutputStream (oStream) ; 
transformADU. serialize (dos) ; 
serializedData  =  oStream. toByteArray () ; 
return  serializedData; 

} 


^  -k  -k 

*  Receives  a  packet  from  the  EntityDispatcher  (or  whatever.)  The 

*  data  we  get  in  is  just  an  array  of  bytes — we  have  to  interpret 

those 

*  bytes  so  that  we  can  do  something  with  them.  This  consists  of  two 

*  things :  determing  syntax,  so  we  can  retrieve  the  field  named 

*  "position . x" ;  and  determining  semantics,  so  we  know  that 

position . X 

*  refers  to  the  location  of  the  entity  in  3-space.  We  instantiate 

*  an  ADUData  packet,  lay  it  out  in  the  format  described  by  the 

*  protocol's  XML  document,  and  fill  in  the  packet's  fields  from  the 


69 


*  incoming  byte  stream  data. 

*/ 

public  void  receivePacket (byte [ ]  pData,  NetworkAware  entity) 

{ 

ByteArraylnputStream  bais  =  new  ByteArrayInputStream (pData) ; 

//  Temporary  workaround;  prevents  EntityMasters  from  being 
//  modified  remotely 

if (entity  instanceof  EntityMaster )  return; 
if (entity  instanceof  DBPTransformableMaster)  return; 

//We  only  get  packets  of  one  type,  so  we  don't  need  to  check 
//  on  format  beforehand  (famous  last  words) . 

ADUData  packet  =  null; 

packet  =  hiResDabpProtocol . binaryDataToADU (pData) ;  //binaryDataToADU 
try 
{ 

if (  ( (UnsignedByte) (packet . get ( "markerValue" ))) .byteValue ( )  ==  98) 

{ 

if (( (UnsignedByte) (packet . get ( "packetResolution . resolution" )) ) . byteValue ( )  == 

1) 

{  packet  =  loResDabpProtocol .binaryDataToADU (pData) ; 

/ /binaryDataToADU 

}//  end  if 

//  some  temporary  variables 

double  transformArray  []  =  new  double [16]; 

double  valuel,  value2,  valued,  value4,  valued,  valued,  valued, 

values, 

value9,  valuelO,  valuell,  valuel2,  valuelS,  valuel4, 

valueld, 

valuel 6; 
int  count  =  0; 

String  intString; 

String  fields  =  "ArrayValues . value" ; 

Object  arrayVals; 

while (count  <=  15) 

{ 

intString  =  Integer . toString (count )  ; 
fields  =  fields  +  intString; 
arrayVals  =  packet . get ( fields ) ; 
transformArray [count]  = 

( (PrimitiveNumber) arrayVals ) . doubleValue ( ) ; 

fields  =  "ArrayValues .value" ; 
count++; 

} / / end  while 

TransformSD  transform  =  new  TransformSD (transformArray) ; 

( (DBPTransformable) entity ) . setTransform (transform) ; 

//  System . out .println ( "Receive  side  — 

Transf ormProtocol : receivePacket (): packet  ==  "+  packet); 

}//  end  if 
else 

{  System. err . println ( "Wrong  marker  type  (not  98)"); 

}//  end  else 

} / /  end  try 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found!  "  +  fnfe); 

}//  end  catch 
return; 
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}//  end  receivePacket  ( ) 


^  -k  -k 

*  Invoked  when  an  entity  is  modified.  The  entity's  transform 

information 

*  is  loaded  into  an  ADUData  packet,  which  is  then  serialized  and 

passed 

*  to  the  Entity  Master. 

*/ 

public  void  entityChanged (Entity  e.  Object  info) 

{ 

if (e  instanceof  DBPTransformableGhost)  return; 

ADUData  transformADU  =  null; 
transformADU  =  new  ADUData (new 
ADU (hiResDabpProtocol . getSchemaNamed ( "TPPPDU" ) ) ) ; 

if (resolution  ==  1) 

{  transformADU  =  new  ADUData (new 
ADU (loResDabpProtocol . getSchemaNamed ( "TPPPDU" ) ) ) ; 

} 


//load  VectorSd  position 

double [ ]  transf ormArray  =  new  double [16]; 

TransformSD  transform  =  new  Transf orm3D () ; 

( (DBPTransformable) e) . getTransform (transf orm) ; 
transform. get (transformArray ) ; 

int  count  =  0; 

String  intString; 

String  fields  =  "ArrayValues . value" ; 

//write  the  resolution  value 
try 
{ 

transf ormADU .put ( "packet Re solution .resolution" ,  new 
UnsignedByte (resolution) ) ; 

}//  end  try 

catch (FieldTypeException  fte) 

{  System. err .println ( "Field  Type  not  found:  "  +  fte); 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{  System. err .println ( "Field  not  found:  "  +  fnfe); 

}//  end  catch 

while (count  <=  15) 

{ 

intString  =  Integer . toString (count ) ; 
fields  =  fields  t  intString; 

try 

{ 

//  giving  up  some  efficiency  here  to  maximize  flexibility  & 

robustness . 

/ /  Can  set  the  fields  types  individually  by  type  in  the  XML 

document 

if (transformADU . get ( fields )  instanceof  DoublePrecision) 
transformADU. put (fields,  new 
DoublePrecision (transformArray [count] ) )  ; 

else  if (transformADU . get (fields)  instanceof  SinglePrecision) 
transformADU. put (fields,  new 
SinglePrecision ( (float) transformArray [count] ) )  ; 

}//  end  try 
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+  fte) ; 


catch (FieldTypeException  fte) 

{  System. err .println ( "Field  Type  not  found:  " 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{  System. err .println ( "Field  not  found:  "  +  fnfe); 

}//  end  catch 

fields  =  "ArrayValues . value" ; 
count+l; 

} / / end  while 

//  System . out .println (" Send  side  - 

Transf ormProtocol : entityChanged ( ) : transf ormADU  ==  "  + 
transformADU) ;//*************888888888888888888 

//  first  time  thru  and  field  values  may  be  null 
if (transformADU . getAduName ( )  ==  "")  return; 

//  Serialize  and  send  transform  data  for  the  entity 
byte[]  data  =  serializeADU (transformADU) ; 

Set  distroSet  =  AOIM. getAOIM ( ) . getDistributionSet (e,  this); 

EntityDispatcher . getEntityDispatcher ( )  . sendPacket (this , 

e . getID ( ) , 
distroSet, 
data) ; 

}//  end  entityChanged ( ) 


C.  DBP  TRANSFORM  HIGH  RESOLUTION  XML  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="TRANSFORM_PACKET" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
clientStub="http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . DoubleP reels ion" 
value=" f ile : //org . web3d. vrtp . datatypes . DoublePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 
value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 
value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Channel  multicastAddress="225 .6.9.121" 

multicastPort  =  "1616"  /> 

<PacketHeader  name="TPP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 
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< /Packet Header > 


<ADU  name="TPPPDU"  markerValue=" 98 "> 

<Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue="98"/> 

<Structure  name= " packet Res oluti on "> 

<Field  name="resolution" 

type="org . webSd. vrtp . datatypes . UnsignedByte" 
initialValue="2"/> 

</ Structure> 

<Structure  name="ArrayValues"> 

<Field  name="valueO " 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel " 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value2 " 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value3" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value4 " 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value5" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value6" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value7 " 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value8 " 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="value9" 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuelO" 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuell" 
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type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel2 " 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel3" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel4" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel5" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 " /> 

</ Strueture> 

</ADU> 

</Protoeol> 


D.  DBP  TRANSFORM  LOW  RESOLUTION  XML  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protoeol  SYSTEM  " . /DynamieBehaviorProtoeol . dtd" > 

<Protoeol  name="TRANSFORM_PACKET" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
elientStub="http : //some . url . eom/baz "> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f lie : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f lie : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . SingleP reels ion" 

value=" f lie : //org . web3d. vrtp . datatypes . SinglePreeision"></Type> 

<Channel  multieastAddress="225 .6.9.121" 

multieastPort  =  "1616"  /> 

<PaoketHeader  name="TPP"> 

<Field  name="sequenee" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


</Paeket Header > 

<ADU  name="TPPPDU"  markerValue=" 98 "> 

<Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue="98"/> 
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<Structure  name= " packet Resolut i on "> 


<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 1 " /> 


</ Structure> 

<Structure  name="ArrayValues"> 

<Field  name="valueO " 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel " 

tYpe="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value2 " 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value3" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value4 " 

tYpe="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value5" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value6" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value7 " 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value8 " 

tYpe="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="value9" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="valuelO" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="valuell" 

tYpe="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel2 " 

tYpe="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 
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<Field  name="valuel3" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel4" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 


<Field  name="valuel5" 

type="org . web3d . vrtp . datatypes . Single? reels ion" 
initialValue=" 0 " /> 

</ Strueture> 

</ADU> 

</?rotoeol> 


E.  SUMMARY 

The  source  code  and  source  documents  presented  in  this  appendix  work  together 
to  provide  both  a  high  and  low  resolution  capabihty  for  the  DBP  transform  protocol. 
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APPENDIX  B 


A.  INTRODUCTION 

This  appendix  provides  the  Java  and  XML  source  code  for  the  DBF  Inertia 
protocol. 

B.  DBF  INERTIA  JAVA  SOURCE  CODE 

package  org . npsnet . v . test . dabp . dbp foundation . dbputil; 

import  java.io.*; 
import  java.net.*; 
import  java . util .* ; 
import  java . util .Vector .* ; 
import  javax . vecmath . *; 
import  javax .media . j 3d .* ; 
import  java . lang . * ; 

import  org . npsnet . V . sys .* ; 
import  org . npsnet . V . net .* ; 

import  org . npsnet . v . test . dabp . dbpfoundation . *; 
import  org . npsnet . v . test . dabp . dbpfoundation . dbputil . *; 
import  org . web3d. vrtp . dabp ; 
import  org . web3d. vrtp . datatypes . * ; 

y  *  * 

*  A  protocol  that  passes  information  about  inertial  state  (position, 

*  linear  and  angular  velocity) . 

*  @author  Bill  Fischer 
*/ 

public  class  DBPInertiaProtocol  extends  org . npsnet . v . sys . Protocol 
implements  Serializable 
{ 

^  -k  -k 

*  The  class's  version  string. 

*/ 

private  static  final  String  classVersion  =  "$Revision:  1.3  $ " ; 

^  -k  -k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  classCodebaseString  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

^  -k  -k 

*  The  singleton  instance  of  this  class. 

*/ 

private  static  DBPInertiaProtocol  inertiaProtocol; 

^  -k  -k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  PROTO_URL  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

^  -k  -k 
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*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  hiXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/ Inert iaP rot ocolPacket . xml" )  ; 

^  -k  -k 

*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  loXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/ Inert iaProtocolPacketLoRes . xml " 

) ; 


^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  hiResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (hiXmlFile)  ; 

^  -k  -k 

*  DABP  protocols  for  low  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  loResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (loXmlFile)  ; 

^  -k  -k 

*  Returns  this  class's  version  string. 

*/ 

public  String  getClassVersion ( )  { 

return  classVersion; 

} 


^  -k  -k 

*  Returns  this  class's  codebase. 

*/ 

public  URL  getClassCodebase ( )  { 

try  {  return  new  URL (classCodebaseString) ;  } 

catch (MalformedURLException  e)  {  return  null;  } 

} 


*  Returns  the  singleton  instance  of  <code>Transf ormProtocol</code> . 
*/ 

public  static  DBPInertiaProtocol  getinstance ( )  { 

if (inertiaProtocol ! =null)  return  inertiaProtocol; 
else  { 

try  { 

org . npsnet . V . sys . Protocol  tmpProt  = 

get Singlet on ( "org . npsnet . v . test . dabp . dbp foundation . dbputil . DBPInertiaProtocol" , 
classVersion) ; 


if (tmpProt  ==  null) 

inertiaProtocol  =  new  DBPInertiaProtocol () ; 

else 

inertiaProtocol  =  (DBPInertiaProtocol) tmpProt; 

} 

catch ( IDServerException  ise)  { 

System. out .println (ise)  ; 

System . exit ( 1 )  ; 

} 
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return  inertiaProtocol; 


^  -k  -k 

*  Constructor;  takes  a  few  parameters,  which  allow  us 

*  to  operate  in  the  world. <p> 

■k 

*  Note  that  this  constructor  is  for  use  with  new  EntityMasters — 

*  We  create  a  new  entity  and  send  out  information  on  it.  The 

*  creation  of  the  entity  registers  a  new  entity  ID  and  new 

protocolIDs 

*  to  go  along  with  it . <p> 

■k 

*  @param  pEntity  entity  that  we  update 
*/ 

public  DBPInertiaProtocol ( )  throws  IDServerException 

{ 

//  A  new  instance  requires  a  new  ID 
super ( "DBPInertiaProtocol" ,  true) ; 

} 


^  -k  -k 

*  constructor.  Note  that  this  constructor  is  for  use  with 

*  things  we  have  discovered  from  the  net.  we  get  in  a  new 

*  message  with  an  existing  ID.  That  means  we  don't  have  to 

*  look  up  the  ID  on  the  IDServer.<p> 

•k 

*  @param  pID  id  of  the  protocol,  gleaned  from  network  traffic 
*/ 

public  DBPInertiaProtocol ( long  pID)  throws  IDServerException 

{ 

super (pID,  IDCache . getIDCache ( ) . getNameForlD (pID) ) ; 

} 


^  -k  -k 

*  This  receives  a  packet  from  the  entity  and  serializes  it,  ie, 

changes 

*  all  the  data  fields  into  a  byte  array  that  we  can  send  across  the 

*  network.  ADU  is  some  nominal  superclass  from  DABP  that  subsumes 

all 

*  packets. 

*/ 

public  byte[]  serializeADU (Ob ject  pPacketData) 

{ 

byte  serializedData [ ]  =  null; 

ADUData  inertiaADU  =  null; 

inertiaADU  =  (ADUData) pPacketData; 

ByteArrayOutputStream  oStream  =  new  ByteArrayOutputStream ( ) ; 
DataOutputStream  dos  =  new  DataOutputStream (oStream) ; 
inertiaADU .serialize (dos)  ; 
serializedData  =  oStream . toByteArray () ; 
return  serializedData; 

} 


^  -k  -k 

*  Receives  a  packet  from  the  EntityDispatcher  (or  whatever.)  The 

*  data  we  get  in  is  just  an  array  of  bytes — we  have  to  interpret 

those 

*  bytes  so  that  we  can  do  something  with  them.  This  consists  of  two 

*  things :  determing  syntax,  so  we  can  retrieve  the  field  named 
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*  "position . x" ;  and  determining  semantics,  so  we  know  that 

position . X 

*  refers  to  the  location  of  the  entity  in  3-space.  We  instantiate 

*  an  ADUData  packet,  lay  it  out  in  the  format  described  by  the 

*  protocol's  XML  document,  and  fill  in  the  packet's  fields  from  the 

*  incoming  byte  stream  data. 

*/ 

public  void  receivePacket (byte [ ]  pData,  NetworkAware  entity) 

{ 

ByteArraylnputStream  bais  =  new  ByteArrayInputStream (pData) ; 

//  Temporary  workaround;  prevents  EntityMasters  from  being 
//  modified  remotely 

if (entity  instanceof  EntityMaster )  return; 
if (entity  instanceof  DBPInertialMaster)  return; 

//We  only  get  packets  of  one  type,  so  we  don't  need  to  check 
//  on  format  beforehand  (famous  last  words) . 

ADUData  packet  =  null; 

packet  =  hiResDabpProtocol . binaryDataToADU (pData) ;  //binaryDataToADU 

//  some  temporary  objects  &  variables 
VectorSd  position  =  null; 

VectorSd  linearVelocity  =  null; 

VectorSd  angularVelocity  =  null; 

Quat4d  orientation  =  null; 
long  posRefTime  =  0; 
long  orRefTime  =  0; 
boolean  timeCorrect  =  true; 
boolean  lowResPacket  =  false; 

try 

{ 

if (  ( (UnsignedByte) (packet . get ( "markerValue" ))) .byteValue ( )  ==  99) 

{ 

if (( (UnsignedByte) (packet . get ( "packetResolution . resolution" )) ) . byteValue ( )  == 

1) 

{  packet  =  loResDabpProtocol .binaryDataToADU (pData) ; 

/ /binaryDataToADU 

}//  end  if 

//  some  temporary  variables 

double  xPos,  yPos,  zPos,  orl,  or2,  or3,  or4,  linX,  linY,  linZ, 
angX,  angY,  angZ; 

//  fill  the  blank  ADUData  packet  with  the  corresponding  fields  from 

the 

//  incoming  byte  stream 
xPos  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "Position . x" ) ) . doubleValue ( ) ) ; 
yPos  = 

(double) ( ( (PrimitiveNumber) packet . get ( "Position . y" ) ) . doubleValue ( ) ) ; 
zPos  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "Position . z" ) ) . doubleValue ( ) ) ; 
position  =  new  Vector3d (xPos ,  yPos,  zPos) ; 

PrimitiveNumber  posPrim  = 

( (PrimitiveNumber ) packet . get ( "posRefTime . posTime" ) )  ; 
if (posPrim  instanceof  Longinteger) 

posRefTime  =  (long) (posPrim. longValue ()) ; 

else  if (posPrim  instanceof  Unsignedinteger ) 
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{ 

long  sysTime  =  System. currentTimeMillis ()  ; 
long  timeMask  =  Oxffffffff 000000001; 
sysTime  =  sysTime  &  timeMask; 
long  tempint  =  posPrim. longValue ( ) ; 
posRefTime  =  (sysTime  |  tempint); 

}//  end  else  if 

PrimitiveNumber  orPrim  = 

( (PrimitiveNumber) packet . get ( "orRefTime . orTime" ) ) ; 

if (orPrim  instanceof  Longinteger) 

orRefTime  =  (long) (posPrim. longValue ()) ; 
else  if (orPrim  instanceof  Unsignedinteger) 

{ 

long  sysTime  =  System. currentTimeMillis () ; 
long  timeMask  =  Oxffffffff 000000001; 
sysTime  =  sysTime  &  timeMask; 
long  tempint  =  orPrim. longValue () ; 
orRefTime  =  (sysTime  |  tempint); 

}//  else  if 

orl  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "orientation . orl " ) ) . doubleValue ( ) ) ; 
or2  = 

(double) ( ( (PrimitiveNumber) packet . get ( "orientation . or2 " ) ) . doubleValue ( ) ) ; 
or3  = 

(double) ( ( (PrimitiveNumber) packet . get ( "orientation . or3 ") ) . doubleValue ( ) ) ; 
or4  = 

(double) ( ( (PrimitiveNumber) packet . get ( "orientation . or4 " ) ) . doubleValue ( ) ) ; 
orientation  =  new  Quat4d(orl,  or2,  or3,  or4); 

linX  = 

(double) ( ( (PrimitiveNumber) packet . get ( "linearVelocity . x" ) ) . doubleValue ( ) ) ; 
linY  = 

(double) ( ( (PrimitiveNumber) packet . get ( "linearVelocity . y" ) ) . doubleValue ( ) ) ; 
linZ  = 

(double) ( ( (PrimitiveNumber) packet . get ( "linearVelocity . z " ) ) . doubleValue ( ) ) ; 
linearVelocity  =  new  Vector3d (linX,  linY,  linZ)  ; 

angX  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "angularVelocity . x" ) ) . doubleValue ( ) 

)  ; 

angY  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "angularVelocity . y " ) ) . doubleValue ( ) 

)  ; 

angZ  = 

(double) ( ( (PrimitiveNumber) packet . get ( "angularVelocity . z " ) ) . doubleValue ( ) 

)  ; 

angularVelocity  =  new  Vector3d (angX,  angY,  angZ)  ; 

//  System . out .println ( "Receive  side  — 

InertiaProtocol : receivePacket (): packet  ==  "+  packet); 

( (DBPInertial ) entity ) . setInertialState (position,  posRefTime, 

orientation, 

orRefTime,  linearVelocity, 
angularVelocity,  1); 

}//  end  if 
else 

{  System. err . println ( "Wrong  marker  type  (not  99)"); 

}//  end  else 
} / /  end  try 

catch (FieldNotFoundException  fnfe) 
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{ 

System . err .println ( "Field  not  found!  "  +  fnfe)  ; 
}//  end  catch 
return; 

} 


^  -k  -k 

*  Invoked  when  an  entity  is  modified.  The  entity's  inertia 

information 

*  is  loaded  into  an  ADUData  packet,  which  is  then  serialized  and 

passed 

*  to  the  Entity  Master. 

*/ 

public  void  entityChanged (Entity  e.  Object  info) 

{ 

if (e  instanceof  DBPInertialGhost )  return; 

ADUData  inertiaADU  =  null; 

inertiaADU  =  new  ADUData (new 
ADU (hiResDabpProtocol . getSchemaNamed ( " IPPPDU" ) ) ) ; 

if (resolution  ==  1) 

inertiaADU  =  new  ADUData (new 
ADU (loResDabpProtocol . getSchemaNamed ( " IPPPDU" ) ) ) ; 

//load  VectorSd  position 

double [ ]  positionArray  =  new  double [3]; 

Vector3d  position  =  new  Vector3d(); 

( (DBPInertial) e)  .getPosition (position)  ; 
position. get (positionArray)  ; 

double  xPos  =  positionArray [ 0 ] ; 
double  yPos  =  positionArray [ 1 ] ; 
double  zPos  =  positionArray [ 2 ] ; 

//  orientation 

double [ ]  orientationArray  =  new  double [4]; 

Quat4d  orientation  =  new  Quat4d(); 

( (DBPInertial) e)  . getOrientation (orientation)  ; 
orientation . get (orientationArray)  ; 

double  orl  =  orientationArray [ 0 ] ; 
double  or2  =  orientationArray [ 1 ]  ; 
double  or3  =  orientationArray [2] ; 
double  or4  =  orientationArray [ 3 ]  ; 

//  linear  velocity 

double [ ]  linearVelocityArray  =  new  double [3]; 

Vector3d  linearVelocity  =  new  Vector3d(); 

( (DBPInertial) e) . getLinearVelocity (linearVelocity) ; 
linearVelocity . get (linearVelocityArray) ; 

double  linX  =  linearVelocityArray [ 0 ] ; 
double  linY  =  linearVelocityArray [ 1 ] ; 
double  linZ  =  linearVelocityArray [2 ] ; 

//  angular  velocity 

double [ ]  angularVelocityArray  =  new  double [3]; 
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Vector3d  angularVelocity  =  new  Vector3d(); 

( (DBPInertial) e) . getAngularVelocity (angularVelocity) ; 
angularVelocity . get (angularVelocityArray ) ; 

double  angX  =  angularVelocityArray [ 0 ]  ; 
double  angY  =  angularVelocityArray [ 1 ] ; 
double  angZ  =  angularVelocityArray [2 ]  ; 
try 
{ 

//  load  the  ADUData  packet 

inertiaADU .put ( "packet Re solution .resolution" ,  new 
UnsignedByte (resolution) ) ; 

String  tempString  =  new  String("Position.x"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (xPos ))  ; 
else  if ( inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision (( float ) xPos ) ) 

tempString  =  new  String ( "Position . y" ) ; 

if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (yPos )) ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision (( float ) yPos ) ) 

tempString  =  new  String ( "Position . z ") ; 

if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision ( zPos )) ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) zPos) ) 

tempString  =  new  String ( "posRefTime .posTime" ) ; 
if (inertiaADU . get (tempString)  instanceof  Longinteger) 
inertiaADU. put (tempString,  new 
Longinteger (System. currentTimeMillis ( ) ) ) ; 

else  if (inertiaADU . get (tempString)  instanceof  Unsignedinteger ) 

{ 

long  sysTime  =  System. currentTimeMillis () ; 
sysTime  =  sysTime  &  OxOOOOOOOOf f ff f f f fl; 
int  tempint  =  (int) sysTime; 

Unsignedinteger  usIntTime  =  new  Unsignedinteger (tempint) ; 
inertiaADU. put (tempString,  usIntTime)  ; 

}//  end  else  if 

tempString  =  new  String ( "orRefTime . orTime" ) ; 
if (inertiaADU. get (tempString)  instanceof  Longinteger) 
inertiaADU. put (tempString,  new 
Longinteger (System. currentTimeMillis ( ) ) ) ; 

else  if ( inertiaADU . get (tempString)  instanceof  Unsignedinteger) 

{ 

long  sysTime  =  System. currentTimeMillis () ; 
sysTime  =  sysTime  &  OxOOOOOOOOf fffffffl; 
int  tempint  =  (int) sysTime; 

Unsignedinteger  usIntTime  =  new  Unsignedinteger (tempint) ; 
inertiaADU. put (tempString,  usIntTime)  ; 

}//  end  else  if 

tempString  =  new  String("orientation.orl"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (orl )) ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision (( float ) orl ))  ; 
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tempString  =  new  String("orientation.or2"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (or2 )) ; 
else  if ( inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) or2) )  ; 

tempString  =  new  String ( "orientation . or3 ") ; 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (or3 ))  ; 
else  if ( inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) or3) ) ; 

tempString  =  new  String("orientation.or4"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (or4 )) ; 
else  if ( inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision (( float ) or4 )) ; 

tempString  =  new  String("linearVelocitY.x"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (linX) ) ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision (( float ) linX) ) 

tempString  =  new  String ( "linearVelocity . y" ) ; 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (linY) ) ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) linY) ) 

tempString  =  new  String("linearVelocity.z"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (linZ) )  ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) linZ) ) 

tempString  =  new  String("angularVelocity.x"); 
if (inertiaADU . get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (angX) ) ; 
else  if (inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) angX) ) 

tempString  =  new  String ( "angularVelocity . y" ) ; 
if (inertiaADU. get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (angY) ) ; 
else  if ( inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision (( float ) angY) ) 

tempString  =  new  String ( "angularVelocity . z ") ; 
if (inertiaADU. get (tempString)  instanceof  DoublePrecision) 
inertiaADU. put (tempString,  new  DoublePrecision (angZ ))  ; 
else  if ( inertiaADU . get (tempString)  instanceof  SinglePrecision) 
inertiaADU. put (tempString,  new  SinglePrecision ( (float) angZ) ) 

}//  end  try 

catch (FieldTypeException  fte) 

{ 

System . err .println ( "Field  Type  not  found:  "  +  fte); 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{ 

System . err .println ( "Field  not  found:  "  +  fnfe); 


84 


}//  end  catch 


//  System . out .println (" Send  side  - 

InertiaProtocol : entityChanged ( )  : inertiaADU  ==  \n"  +  inertiaADU)  ; 

//  Serialize  and  send  inertial  data  for  the  entity 
//  Serialize  and  send  transform  data  for  the  entity 
byte [ ]  data  =  serializeADU (inertiaADU) ; 

Set  distroSet  =  AOIM. getAOIM ( ) . getDistributionSet (e,  this); 

EntityDispatcher . getEntityDispatcher ( ) . sendPacket (this , 

e . getID ( ) , 
distroSet, 
data) ; 


}; 


C.  DBP  INERTIA  HIGH  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="INERTIAL_PACKET" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
clientStub="http : //some . url . com/baz "> 


<Type  name="org . web3d . vrtp . datatypes . DoubleP reels ion" 

value=" f ile : //org . web3d. vrtp . datatypes . DoublePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Longinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Longinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Channel  multicastAddress="225 .4.3. 122 " 

multicastPort  =  "1717"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

< /Packet Header > 

<ADU  name=" IPPPDU"  markerValue=" 99"> 

<Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 99" /> 

<Structure  name="packetResolution"  initialValue  =  "2"> 
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<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue="2"/> 

</ Structure> 

<Structure  name="Position"> 

<Field  name="x" 

type="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name  ="posRefTime"> 

<Field  name="posTime" 

type="org . web3d. vrtp . datatypes . Longinteger " 
initialValue=" 0 " /> 

</ Structure> 

<Structure  name  ="orRefTime"> 

<Field  name="orTime" 

type="org . web3d. vrtp . datatypes . Longinteger" 
initialValue=" 0 " /> 

</ Structure> 

<Structure  name="orientation"> 

<Field  name="orl" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="or2" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="or3" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="or4" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name="linearVelocity "> 

<Field  name="x" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 
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<Field  name="y" 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

tYpe="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name="angularVelocity "> 

<Field  name="x" 

tYpe="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

tYpe="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 


D.  DBP  INERTIA  LOW  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="INERTIAL_PACKET" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
cl lent St ub=" http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . SingleP reels ion" 

value=" f ile : //org . web3d. vrtp . datatypes . SinglePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></TYpe> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . Unsignedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Unsignedinteger "></Type> 

<Channel  multicastAddress="225 .4.3. 122  " 

multicastPort  =  "1717"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 
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< /Packet Header > 


<ADU  name=" IPPPDU"  markerValue=" 99"> 

<Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 99" /> 


<Structure  name="packetResolution"  initialValue  =  "1"> 
<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 1 " /> 


</ Structure> 

<Structure  name="Position"> 

<Field  name="x" 

type="org . web3d . vrtp . datatypes . SinglePrecision 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . SinglePrecision 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

type="org . web3d . vrtp . datatypes . SinglePrecision 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name  ="posRefTime"> 

<Field  name="posTime" 

type="org . web3d. vrtp . datatypes . Unsignedinteger " 
initialValue=" 0 " /> 


</ Structure> 

<Structure  name  ="orRefTime"> 

<Field  name="orTime" 

type="org . web3d. vrtp . datatypes . Unsignedinteger" 
initialValue=" 0 " /> 


</ Structure> 

<Structure  name="orientation"> 

<Field  name="orl" 

type="org . web3d . vrtp . datatypes . SinglePrecision 
initialValue=" 0 . 0 " /> 

<Field  name="or2" 

type="org . web3d . vrtp . datatypes . SinglePrecision 
initialValue=" 0 . 0 " /> 

<Field  name="or3" 

type="org . web3d . vrtp . datatypes . SinglePrecision 
initialValue=" 0 . 0 " /> 

<Field  name="or4" 


88 


tYpe="org . web3d . vrtp . datatypes . SingleP reels ion" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name="linearVelocity "> 

<Field  name="x" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name="angularVelocity "> 

<Field  name="x" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 


E.  SUMMARY 

The  source  code  and  source  documents  presented  in  this  appendix  work  together 
to  provide  both  a  high  and  low  resolution  capabihty  for  the  DBP  inertia  protocol. 
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APPENDIX  C 


A.  INTRODUCTION 

This  appendix  provides  the  Java  and  XML  source  code  for  the  DBF  Animation 
protocol. 

B.  DBF  ANIMATION  JAVA  SOURCE  CODE 

package  org . npsnet . v . test . dabp . dbp foundation . dbputil; 

import  java.io.*; 

import  java.net.*; 

import  java . util .* ; 

import  java . util .Vector .* ; 

import  javax . vecmath . *; 

import  javax .media . j 3d .* ; 

import  java . lang . * ; 

import  org . npsnet . V . sys .* ; 
import  org . npsnet . V . net .* ; 

import  org . npsnet . v . test . dabp . dbpfoundation . *; 
import  org . npsnet . v . test . dabp . dbpfoundation . dbputil . *; 
import  org . web3d. vrtp . dabp .* ; 
import  org . web3d. vrtp . datatypes . * ; 

!  -k  -k 

*  A  protocol  for  transmitting  information  about  simple,  independent 

*  animations  with  integer  identifiers. 

* 

*  @author  Bill  Fischer 
*/ 

public  class  DBPAnimationProtocol  extends  org . npsnet .v . sys . Protocol 
implements  Serializable 
{ 

j  k  k 

*  The  class's  version  string. 

*/ 

private  static  final  String  classVersion  =  "$Revision:  1.3  $ " ; 

I  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  classCodebaseString  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 

*  The  singleton  instance  of  this  class. 

*/ 

private  static  DBPAnimationProtocol  animationProtocol; 

j  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  PROTO_URL  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 

*  The  URL  to  the  XML  file  describing  the  packet  layout 
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*/ 

string  hiXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/AnimationP rot ocolPacket . xml" )  ; 

^  -k  -k 

*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  loXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/AnimationP rot ocolPacket . xml" )  ; 

^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  hiResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (hiXmlFile)  ; 

^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  loResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (loXmlFile)  ; 

^  -k  -k 

*  Returns  this  class's  version  string. 

*/ 

public  String  getClassVersion ( )  { 

return  classVersion; 

} 


^  -k  -k 

*  Returns  this  class's  codebase. 

*/ 

public  URL  getClassCodebase ( )  { 

try  {  return  new  URL (classCodebaseString)  ;  } 

catch (MalformedURLException  e)  {  return  null;  } 

} 


^  -k  -k 

*  Returns  the  singleton  instance  of  <code>AnimationProtocol</code> . 
*/ 

public  static  DBPAnimationProtocol  getinstance ( )  { 

if (animationProtocol ! =null)  return  animationProtocol ; 
else  { 

try  { 

org . npsnet . V. sys . Protocol  tmpProt  = 

get Singlet on ( "org . npsnet . v . test . dabp . dbp foundation . dbputil . DBP Animat ionPr 
otoc  ol" ,  classVersion)  ; 

if (tmpProt  ==  null) 

animationProtocol  =  new  DBPAnimationProtocol () ; 

else 

animationProtocol  =  (DBPAnimationProtocol) tmpProt; 

} 

catch ( IDServerException  ise)  { 

System. out .println (ise)  ; 

System . exit ( 1 )  ; 

} 

return  animationProtocol; 


^  -k  -k 
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*  Constructor;  takes  a  few  parameters,  which  allow  us 

*  to  operate  in  the  world. <p> 

•k 

*  Note  that  this  constructor  is  for  use  with  new  EntityMasters — 

*  We  create  a  new  entity  and  send  out  information  on  it.  The 

*  creation  of  the  entity  registers  a  new  entity  ID  and  new 

protocolIDs 

*  to  go  along  with  it . <p> 

•k 

*  @param  pEntity  entity  that  we  update 
*/ 

public  DBPAnimationProtocol ( )  throws  IDServerException 

{ 

//  A  new  instance  requires  a  new  ID 

super ( "DBPAnimationProtocol " ,  true) ; 

} 

^  -k  -k 

*  constructor.  Note  that  this  constructor  is  for  use  with 

*  things  we  have  discovered  from  the  net.  we  get  in  a  new 

*  message  with  an  existing  ID.  That  means  we  don't  have  to 

*  look  up  the  ID  on  the  IDServer.<p> 

•k 

*  @param  pID  id  of  the  protocol,  gleaned  from  network  traffic 
*/ 

public  DBPAnimationProtocol (long  pID)  throws  IDServerException 

{ 

super (pID,  IDCache . getIDCache ( ) . getNameForlD (pID) ) ; 

} 


^  -k  -k 

*  This  receives  a  packet  from  the  entity  and  serializes  it,  ie, 

changes 

*  all  the  data  fields  into  a  byte  array  that  we  can  send  across  the 

*  network.  ADU  is  some  nominal  superclass  from  DABP  that  subsumes 

all 

*  packets. 

*/ 

public  byte[]  serializeADU (Ob ject  pPacketData) 

{ 

byte  serializedData [ ]  =  null; 

ADUData  animationADU  =  null; 

animationADU  =  (ADUData) pPacketData; 

ByteArrayOutputStream  oStream  =  new  ByteArrayOutputStream ( ) ; 
DataOutputStream  dos  =  new  DataOutputStream (oStream) ; 

animationADU. serialize (dos)  ; 
serializedData  =  oStream . toByteArray () ; 

return  serializedData; 

} 


^  -k  -k 

*  Receives  a  packet  from  the  EntityDispatcher  (or  whatever.)  The 

*  data  we  get  in  is  just  an  array  of  bytes — we  have  to  interpret 

those 

*  bytes  so  that  we  can  do  something  with  them.  This  consists  of  two 

*  things :  determing  syntax,  so  we  can  retrieve  the  field  named 

*  "position . x" ;  and  determining  semantics,  so  we  know  that 

position . X 

*  refers  to  the  location  of  the  entity  in  3-space.  We  instantiate 

*  an  ADUData  packet,  lay  it  out  in  the  format  described  by  the 
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*  protocol's  XML  document,  and  fill  in  the  packet's  fields  from  the 

*  incoming  byte  stream  data. 

*/ 

public  void  receivePacket (byte [ ]  pData,  NetworkAware  entity) 

{ 

ByteArraylnputStream  bais  =  new  ByteArrayInputStream (pData) ; 

//  Temporary  workaround;  prevents  EntityMasters  from  being 
//  modified  remotely 

if (entity  instanceof  EntityMaster )  return; 
if (entity  instanceof  DBPAnimatedMaster )  return; 

//We  only  get  packets  of  one  type,  so  we  don't  need  to  check 
//  on  format  beforehand  (famous  last  words) . 

ADUData  packet  =  null; 

packet  =  hiResDabpProtocol . binaryDataToADU (pData) ;  //binaryDataToADU 
//  some  temporary  objects  &  variables 
boolean  animIsLooping  =  false; 
long  animStartTime  =  0; 
boolean  lowResPacket  =  false; 

try 

{ 

if (  ( (UnsignedByte) (packet . get ( "markerValue" ))) .byteValue ( )  ==  96) 

{ 

if (( (UnsignedByte) (packet . get ( "packetResolution . resolution" )) ) . byteValue ( )  == 

1) 

{  packet  =  loResDabpProtocol .binaryDataToADU (pData) ; 

/ /binaryDataToADU 

}//  end  if 

//  some  temporary  variables 
byte  tempLooping  =  0; 

tempLooping  = 

(byte) ( ( (PrimitiveNumber ) packet . get ( " animat ionLooping .looping" ) ) . byteValu 

e  ( )  )  ; 


PrimitiveNumber  startTimePrim  = 

( (PrimitiveNumber ) packet . get ( "animStartTime . time" ) )  ; 

if (startTimePrim  instanceof  Longinteger) 

animStartTime  =  (long) (startTimePrim. longValue ()) ; 

else  if (startTimePrim  instanceof  Unsignedinteger ) 

{ 

long  sysTime  =  System. currentTimeMillis () ; 
long  timeMask  =  Oxffffffff 000000001; 
sysTime  =  sysTime  &  timeMask; 
long  tempint  =  startTimePrim. longValue () ; 
animStartTime  =  (sysTime  I  tempint); 

}//end  else  if 

animIsLooping  =  tempLooping  ==  1  ?  true  :  false; 

//  System . out .println ( "Receive  side  — 

AnimationProtocol : receivePacket (): packet  ==  "+  packet); 

double  one  =  1; 

( (DBP Animated) entity ) . setAnimation ( (int) (entity . get ID ()) , 
animIsLooping,  animStartTime,  one) ; 

}//  end  if 
else 
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{  System. err . println ( "Wrong  marker  type  (not  96)"); 
}//  end  else 
} / /  end  try 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found!  "  +  fnfe); 
}//  end  catch 
return; 

} 


^  -k  -k 

*  Invoked  when  an  entity  is  modified. 

*/ 

public  void  entityChanged (Entity  e.  Object  info) 

{ 

if (e  instanceof  DBPAnimatedGhost )  return; 

ADUData  animatedADU  =  null; 
animatedADU  =  new  ADUData (new 
ADU (hiResDabpProtocol . getSchemaNamed ( "ANPPPDU" )  )  )  ; 

if (resolution  ==  1) 

{  animatedADU  =  new  ADUData (new 
ADU (loResDabpProtocol . getSchemaNamed ( "ANPPPDU" ) ) )  ; 

}//  end  if 

boolean  animIsLooping  =  ( (DBPAnimated) e) . getAnimIsLooping ( ) ; 
long  animStartTime  =  ( (DBPAnimated) e) . getAnimStartTime () ; 
byte  animLooping  =  (byte) (animIsLooping  ==  true  ?  I  :  0); 

try 

{ 

//  load  the  ADUData  packet 

animatedADU . put ( "packetResolution . resolution" ,  new 
UnsignedByte (resolution) )  ; 

String  tempString  =  new  StringC'animationLooping.looping"); 

if (animatedADU . get (tempString)  instanceof  UnsignedByte) 

animatedADU . put (tempString,  new  UnsignedByte (animLooping) )  ; 
else  if (animatedADU . get (tempString)  instanceof  UnsignedShort ) 
animatedADU . put (tempString,  new 
UnsignedShort ( (short) animLooping) )  ; 

tempString  =  new  String ( "animStartTime . time" ) ; 
if (animatedADU . get (tempString)  instanceof  Longinteger) 

animatedADU . put (tempString,  new  Longinteger (animStartTime) )  ; 
else  if (animatedADU . get (tempString)  instanceof  Unsignedinteger ) 
{ 

long  sysTime  =  System. currentTimeMillis ()  ; 
sysTime  =  sysTime  &  OxOOOOOOOOff f f f f f fl; 
int  tempint  =  (int) sysTime; 

Unsignedinteger  usIntTime  =  new  Unsignedinteger (tempint ) ; 
animatedADU . put (tempString,  usIntTime)  ; 

}//  end  else  if 
}//  end  try 

catch (FieldTypeException  fte) 

{ 

System . err .println ( "Field  Type  not  found:  "  +  fte); 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{ 

System . err .println ( "Field  not  found:  "  +  fnfe); 

}//  end  catch 
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//  System . out .println (" Send  side  - 

AnimationProtocol : entityChanged ( ) : animatedADU  ==  \n"  +  animatedADU) ; 

//  Serialize  and  send  animation  data  for  the  entity 
byte [ ]  data  =  serializeADU (animatedADU) ; 


Set  distroSet  =  AOIM. getAOIM ( ) . getDistributionSet (e,  this); 


EntityDispatcher . getEntityDispatcher ( ) . sendPacket (this , 

e . getID ( ) , 
distroSet, 
data) ; 


}; 


C.  DBP  ANIMATION  HIGH  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="ANIMATION_STATE" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
clientStub="http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . DoubleP reels ion" 

value=" f ile : //org . web3d. vrtp . datatypes . DoublePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Longinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Longinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<! —  <Channel  multicastAddress="225 . 7 . 8 . 30" 

multicastPort  =  "4070"  />  — > 

<Channel  multicastAddress="225 .9.9.127" 

multicastPort  =  "1919"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


< /Packet Header > 

<ADU  name="ANPPPDU"  markerValue= " 9 6 " > 

<Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 96" /> 
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<Structure  name="packetResolution"  initialValue  =  "2"> 
<Field  name="resolution" 

type="org . webSd. vrtp . datatypes . UnsignedByte" 
initialValue="2"/> 

</ Structure> 

<Structure  name  ="animationLooping"> 

<Field  name="looping" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 0 " /> 

</ Structure> 

<Structure  name  ="animStartTime"> 

<Field  name="time" 

type="org . web3d. vrtp . datatypes . Longinteger " 
initialValue=" 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 


D.  DBP  ANIMATION  LOW  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="ANIMATION_STATE" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
clientStub="http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . DoublePrecision" 

value=" f ile : //org . web3d. vrtp . datatypes . DoublePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Longinteger" 

value=" f ile : //org . web3d. vrtp . datatypes . Longinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . Unsignedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Unsignedinteger "></Type> 

<! —  <Channel  multicastAddress="225 . 7 . 8 . 30" 

multicastPort  =  "4070"  />  — > 

<Channel  multicastAddress="225 .9.9.127" 

multicastPort  =  "1919"  /> 

<PacketHeader  name="RTP"> 
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<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger " 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

< /Packet Header > 


<ADU  name="ANPPPDU"  markerValue=" 96"> 

<Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 96" /> 

<Structure  name="packetResolution"  initialValue  =  "1"> 

<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 1 " /> 

</ Structure> 

<Structure  name  ="animationLooping"> 

<Field  name="looping" 

tYpe="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 0 " /> 

</ Structure> 

<Structure  name  ="animStartTime"> 

<Field  name="time" 

tYpe="org . web3d. vrtp . datatypes . Unsignedinteger " 
initialValue=" 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 

E.  SUMMARY 

The  source  code  and  source  documents  presented  in  this  appendix  work  together 
to  provide  both  a  high  and  low  resolution  capabihty  for  the  DBP  animation  protocol. 
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APPENDIX  D 


A.  INTRODUCTION 

This  appendix  provides  the  Java  and  XML  source  code  for  he  DBF  acceleration 
protocol. 

B.  DBF  ACCELERATION  JAVA  SOURCE  CODE 

package  org . npsnet . v . test . dabp . dbp foundation . dbputil; 

import  java.io.*; 
import  java.net.*; 
import  java . util .* ; 
import  java . util .Vector .* ; 
import  javax . vecmath . *; 
import  javax .media . j 3d .* ; 
import  java . lang . * ; 

import  org . npsnet . V . sys .* ; 
import  org . npsnet . V . net .* ; 

import  org . npsnet . v . test . dabp . dbpfoundation . *; 
import  org . npsnet . v . test . dabp . dbpfoundation . dbputil . *; 
import  org . web3d. vrtp . dabp ; 
import  org . web3d. vrtp . datatypes . * ; 

!  -k  -k 

*  A  protocol  that  passes  information  about  linear  and  angular 

*  acceleration. 

*  @author  Bill  Fischer 
*/ 

public  class  DBPAccelerationProtocol  extends  org . npsnet . v . sys . Protocol 
implements  Serializable 
{ 

j  k  k 

*  The  class's  version  string. 

*/ 

private  static  final  String  classVersion  =  "$Revision:  1.2  $ " ; 

j  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  classCodebaseString  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 

*  The  singleton  instance  of  this  class. 

*/ 

private  static  DBPAccelerationProtocol  accelerationProtocol; 

j  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  PROTO_URL  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 
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*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  hiXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/AccelerationProtocolPacket . xml 

) ; 

^  -k  -k 

*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  loXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/AccelerationProtocolPacketLoRe 

.  xml "  )  ; 


^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  hiResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (hiXmlFile)  ; 

^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  loResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (loXmlFile)  ; 

^  -k  -k 

*  Returns  this  class's  version  string. 

*/ 

public  String  getClassVersion ( )  { 

return  classVersion; 

} 


^  -k  -k 

*  Returns  this  class's  codebase. 

*/ 

public  URL  getClassCodebase ( )  { 

try  {  return  new  URL (classCodebaseString) ;  } 

catch (MalformedURLException  e)  {  return  null;  } 

} 


*  Returns  the  singleton  instance  of 
<code>AccelerationProtocol</code> . 

*/ 

public  static  DBPAccelerationProtocol  getinstance ( )  { 

if (accelerationProtocol ! =null)  return  accelerationProtocol; 
else  { 

try  { 

org . npsnet . V . sys . Protocol  tmpProt  = 

get Singlet on ( "org . npsnet . v . test . dabp . dbp foundation . dbputil . DBPAccelerationProto 
col" , classVersion) ; 


if (tmpProt  ==  null) 

accelerationProtocol  =  new  DBPAccelerationProtocol ( ) 

else 

accelerationProtocol  = 

(DBPAccelerationProtocol ) tmpProt ; 

} 

catch ( IDServerException  ise)  { 

System. out .println (ise) ; 

System . exit ( 1 ) ; 
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} 

return  accelerationProtocol; 


^  -k  -k 

*  Constructor;  takes  a  few  parameters,  which  allow  us 

*  to  operate  in  the  world. <p> 

*  Note  that  this  constructor  is  for  use  with  new  EntityMasters — 

*  We  create  a  new  entity  and  send  out  information  on  it.  The 

*  creation  of  the  entity  registers  a  new  entity  ID  and  new 

protocolIDs 

*  to  go  along  with  it . <p> 

•k 

*  @param  pEntity  entity  that  we  update 
*/ 

public  DBF AccelerationProtocol  ( )  throws  IDServerException 

{ 

//  A  new  instance  requires  a  new  ID 

super ( "DBPAccelerationProtocol" ,  true) ; 

} 


^  -k  -k 

*  constructor.  Note  that  this  constructor  is  for  use  with 

*  things  we  have  discovered  from  the  net.  we  get  in  a  new 

*  message  with  an  existing  ID.  That  means  we  don't  have  to 

*  look  up  the  ID  on  the  IDServer.<p> 

•k 

*  @param  pID  id  of  the  protocol,  gleaned  from  network  traffic 
*/ 

public  DBPAccelerationProtocol (long  pID)  throws  IDServerException 

{ 

super (pID,  IDCache . getIDCache ( ) . getNameForlD (pID) ) ; 

} 


^  -k  -k 

*  This  receives  a  packet  from  the  entity  and  serializes  it,  ie, 

changes 

*  all  the  data  fields  into  a  byte  array  that  we  can  send  across  the 

*  network.  ADU  is  some  nominal  superclass  from  DABP  that  subsumes 

all 

*  packets. 

*/ 

public  byte [ ]  serializeADU (Ob ject  pPacketData) 

{ 

byte  serializedData [ ]  =  null; 

ADUData  accelerationADU  =  null; 

accelerationADU  =  (ADUData) pPacketData; 

ByteArrayOutputStream  oStream  =  new  ByteArrayOutputStream ( ) ; 
DataOutputStream  dos  =  new  DataOutputStream (oStream) ; 

accelerationADU. serialize (dos)  ; 
serializedData  =  oStream . toByteArray () ; 

return  serializedData; 

} 

^  -k  -k 

*  Receives  a  packet  from  the  EntityDispatcher  (or  whatever.)  The 

*  data  we  get  in  is  just  an  array  of  bytes — we  have  to  interpret 

those 

*  bytes  so  that  we  can  do  something  with  them.  This  consists  of  two 
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position .  X 


*  things :  determing  syntax,  so  we  can  retrieve  the  field  named 

*  "position . x" ;  and  determining  semantics,  so  we  know  that 

*  refers  to  the  location  of  the  entity  in  3-space.  We  instantiate 

*  an  ADUData  packet,  lay  it  out  in  the  format  described  by  the 

*  protocol's  XML  document,  and  fill  in  the  packet's  fields  from  the 

*  incoming  byte  stream  data. 

*/ 

public  void  receivePacket (byte [ ]  pData,  NetworkAware  entity) 

{ 

ByteArraylnputStream  bais  =  new  ByteArrayInputStream (pData) ; 

//  Temporary  workaround;  prevents  EntityMasters  from  being 
//  modified  remotely 

if (entity  instanceof  EntityMaster )  return; 
if (entity  instanceof  DBPAccelerableMaster )  return; 

//We  only  get  packets  of  one  type,  so  we  don't  need  to  check 
//  on  format  beforehand  (famous  last  words) . 

ADUData  packet  =  null; 

packet  =  hiResDabpProtocol . binaryDataToADU (pData) ;  //binaryDataToADU 

//  some  temporary  objects  &  variables 
VectorSd  linearAcceleration  =  null; 

VectorSd  angularAcceleration  =  null; 


try 

{ 

if (  ( (UnsignedByte) (packet . get ( "markerValue" ))) .byteValue ( )  ==  97) 

{ 


if (( (UnsignedByte) (packet . get ( "packetResolution . resolution" )) ) . byteValue ( )  == 
1) 

{  packet  =  loResDabpProtocol .binaryDataToADU (pData) ; 

/ /binaryDataToADU 

}//  end  if 


//  some  temporary  variables 

double  linX,  linY,  linZ,  angX,  angY,  angZ; 


the 

to 


//  fill  the  blank  ADUData  packet  with  the  corresponding  fields  from 
//  incoming  byte  stream.  Try  separately  in  case  later  we  decide 
//  only  send  a  partial  packet  (eg  linear  and  not  angular) 


try{ 

linX  = 

(double) ( ( (PrimitiveNumber) packet . get ( "linearAcceleration . lax" ) ) . doubleValue ( ) ) 

/ 

linY  = 

(double) ( ( (PrimitiveNumber) packet . get ( "linearAcceleration . lay" ) ) . doubleValue ( ) ) 

/ 

linZ  = 

(double) ( ( (PrimitiveNumber) packet . get ( "linearAcceleration . laz " ) ) . doubleValue ( ) ) 

/ 

linearAcceleration  =  new  VectorSd (linX,  linY,  linZ) ; 

}//  end  try 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found!  "  +  fnfe); 

}//  end  catch 
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try 

{  angX  = 

(double)  ( ( (PrimitiveNumber ) packet . get ( "angularAcceleration .  aax" ) )  . doubleValue ( ) 

)  ; 

angY  = 

(double) ( ( (PrimitiveNumber) packet . get ( "angularAcceleration . aay" ) ) . doubleValue ( ) 

)  ; 

angZ  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "angularAcceleration . aaz " ) ) . doubleValue ( ) 

)  ; 

angularAcceleration  =  new  VectorSd (angX,  angY,  angZ) ; 

}//  end  try 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found!  "  +  fnfe); 

}//  end  catch 

//  System . out .println ( "Receive  side  — 

Transf ormProtocol : receivePacket (): packet  ==  "+  packet); 

if (linearAcceleration  !=  null) 

{ 

( (DBPAccelerable) entity) . setLinearAcceleration (linearAcceleration) ; 

}//  end  if 

if (angularAcceleration  !=  null) 

{ 

( (DBPAccelerable) entity) . setAngularAcceleration (angularAcceleration) ; 

}//  end  if 

}//  end  if 
else 

{  System. err . println ( "Wrong  marker  type  (not  97)"); 

}//  end  else 

} / /  end  try 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found!  "  +  fnfe); 

}//  end  catch 

return; 

} 


^  -k  -k 

*  Invoked  when  an  entity  is  modified.  The  entity's  inertia 

information 

*  is  loaded  into  an  ADUData  packet,  which  is  then  serialized  and 

passed 

*  to  the  Entity  Master. 

*/ 

public  void  entityChanged (Entity  e.  Object  info) 

{ 

if (e  instanceof  DBPAccelerableGhost)  return; 

ADUData  accelerationADU  =  null; 
accelerationADU  =  new  ADUData (new 
ADU (hiResDabpProtocol . getSchemaNamed ( "ACPPPDU" ) ) )  ; 

if (resolution  ==  1) 

{  accelerationADU  =  new  ADUData (new 
ADU (loResDabpProtocol . getSchemaNamed ( "ACPPPDU" ) )  )  ; 

}//  end  if 

//  linear  acceleration 
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double [ ]  linearAccelerationArray  =  new  double [3]; 

Vector3d  linearAcceleration  =  new  Vector3d(); 

( (DBPAccelerable) e)  . getLinearAcceleration (linearAcceleration)  ; 
linearAcceleration . get (linearAccelerationArray) ; 

double  linX  =  linearAccelerationArray [ 0 ]  ; 
double  linY  =  linearAccelerationArray [ 1 ]  ; 
double  linZ  =  linearAccelerationArray [2]  ; 

//  angular  acceleration 

double [ ]  angularAccelerationArray  =  new  double [3]; 

Vector3d  angularAcceleration  =  new  Vector3d(); 

( (DBPAccelerable) e) . getAngularAcceleration (angularAcceleration) ; 
angularAcceleration . get (angularAccelerationArray) ; 

double  angX  =  angularAccelerationArray [ 0 ] ; 
double  angY  =  angularAccelerationArray [ 1 ] ; 
double  angZ  =  angularAccelerationArray [2 ]  ; 
try 
{ 

//  load  the  ADUData  paclcet 

accelerationADU . put ( "packet Re solution . resolution" ,  new 
UnsignedByte (resolution) )  ; 

}//  end  try 

catch (FieldTypeException  fte) 

{  System . err .println ( "Field  Type  not  found:  "  +  fte); 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found:  "  +  fnfe); 

}//  end  catch 

String  tempString  =  new  String (" linearAcceleration . lax" )  ; 

//  doing  this  in  pieces  in  case  we  later  want  to  send  one  without 

the  other 

try 

{ 

if (accelerationADU . get (tempString)  instanceof  DoublePrecision) 
accelerationADU . put (tempString,  new  DoublePrecision ( linX) )  ; 
else  if (accelerationADU . get (tempString)  instanceof 
SinglePrecision) 

accelerationADU . put (tempString,  new 
SinglePrecision ( (float) linX) ) ; 

tempString  =  new  String ( "linearAcceleration . lay" ) ; 
if (accelerationADU . get (tempString)  instanceof  DoublePrecision) 
accelerationADU . put (tempString,  new  DoublePrecision ( linY) ) ; 
else  if (accelerationADU . get (tempString)  instanceof 
SinglePrecision) 

accelerationADU . put (tempString,  new 
SinglePrecision ( (float) linY) ) ; 

tempString  =  new  String("linearAcceleration.laz"); 
if (accelerationADU . get (tempString)  instanceof  DoublePrecision) 
accelerationADU . put (tempString,  new  DoublePrecision (linZ) ) ; 
else  if (accelerationADU . get (tempString)  instanceof 
SinglePrecision) 

accelerationADU . put (tempString,  new 
SinglePrecision ( (float) linZ) ) ; 

}//  end  try 

catch (FieldTypeException  fte) 

{  System . err .println ( "Field  Type  not  found:  "  +  fte); 
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+  fnfe) ; 


}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{  System. err .println ( "Field  not  found:  " 

}//  end  catch 

tempString  =  new  String ( "angularAcceleration . aax" ) ; 
try{ 

if (accelerationADU . get (tempString)  instanceof  DoublePrecision) 
accelerationADU . put (tempString,  new  DoublePrecision (angX) )  ; 
else  if (accelerationADU . get (tempString)  instanceof 
SingleP reels ion) 

accelerationADU . put (tempString,  new 
SinglePrecision ( (float) angX) ) ; 

tempString  =  new  String ( "angularAcceleration . aay" ) ; 
if (accelerationADU . get (tempString)  instanceof  DoublePrecision) 
accelerationADU . put (tempString,  new  DoublePrecision (angY) ) ; 
else  if (accelerationADU . get (tempString)  instanceof 
SinglePrecision) 

accelerationADU . put (tempString,  new 
SinglePrecision ( (float) angY) ) ; 

tempString  =  new  String("angularAcceleration.aaz"); 
if (accelerationADU . get (tempString)  instanceof  DoublePrecision) 
accelerationADU . put (tempString,  new  DoublePrecision (angZ) ) ; 
else  if (accelerationADU . get (tempString)  instanceof 
SinglePrecision) 

accelerationADU . put (tempString,  new 
SinglePrecision ( (float) angZ) ) ; 

}//  end  try 

catch (FieldTypeException  fte) 

{  System . err .println ( "Field  Type  not  found:  "  +  fte); 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{  System . err .println ( "Field  not  found:  "  +  fnfe); 

}//  end  catch 


//  System . out .println (" Send  side  - 

AccelerationProtocol : entityChanged (): accelerationADU  ==  \n"  + 
accelerationADU) ;//*************888888888888888888 

//  Serialize  and  send  inertial  data  for  the  entity 
//  Serialize  and  send  transform  data  for  the  entity 
byte [ ]  data  =  serializeADU (accelerationADU) ; 

Set  distroSet  =  AOIM. getAOIM ( ) . getDistributionSet (e,  this); 

EntityDispatcher . getEntityDispatcher  ( )  . sendPacket (this , 

e . getID ( ) , 
distroSet, 
data) ; 


}; 

C.  DBP  ACCELERATION  HIGH  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 
<Protocol  name="ACCELERATION_STATE" 
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markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
clientStub="http : //some . url . com/baz "> 


<Type  name="org . web3d . vrtp . datatypes . DoubleP reels ion" 

value=" f lie : //org . web3d. vrtp . datatypes . DoublePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Longinteger " 

value=" f lie : //org . web3d. vrtp . datatypes . Longinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Channel  multicastAddress="225 .2.4. 122 " 

multicastPort  =  "1818"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


< /Packet Header > 

<ADU  name="ACPPPDU"  markerValue=" 97 "> 

<! —  <Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 97 " />  — > 

<Structure  name="packetResolution"  initialValue  =  "2"> 
<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue="2"/> 


</ Structure> 

<Structure  name="linearAcceleration"> 

<Field  name="lax" 

tYpe="org . web3d . vrtp . datatypes . DoubleP rec is ion" 
initialValue=" 0 . 0 " /> 

<Field  name="lay" 

tYpe="org . web3d . vrtp . datatypes . DoubleP rec is ion" 
initialValue=" 0 . 0 " /> 

<Field  name="laz" 

tYpe="org . web3d . vrtp . datatYpes . DoubleP rec is ion" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name="angularAcceleration"> 
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<Field  name="aax" 

tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 . 0 " /> 

<Field  name="aay" 

tYpe="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="aaz" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 


D.  DBP  ACCELERATION  LOW  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="ACCELERATION_STATE" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
cl lent St ub=" http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . SingleP reels ion" 
value=" f ile : //org . web3d. vrtp . datatypes . SinglePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Longinteger " 
value=" f ile : //org . web3d. vrtp . datatypes . Longinteger "></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 
value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 
value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<Channel  multicastAddress="225 .2.4. 122 " 

multicastPort  =  "1818"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


< /Packet Header > 

<ADU  name="ACPPPDU"  markerValue=" 97 "> 

<! —  <Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 97 " />  — > 
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<Structure  name="packetResolution"  initialValue  =  "2"> 


<Field  name="resolution" 

type="org . webSd. vrtp . datatypes . UnsignedByte" 
initialValue=" 1 " /> 


</ Structure> 

<Structure  name="linearAcceleration"> 

<Field  name="lax" 

type="org . web3d . vrtp . datatypes . SingleP reels ion" 
initialValue=" 0 . 0 " /> 

<Field  name="lay" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="laz" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

<Structure  name="angularAcceleration"> 

<Field  name="aax" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="aay" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="aaz" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 

E.  SUMMARY 

The  source  code  and  source  documents  presented  in  this  appendix  work  together 
to  provide  both  a  high  and  low  resolution  capabihty  for  the  DBP  acceleration  protocol. 
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APPENDIX  E 


A.  INTRODUCTION 

This  appendix  provides  the  Java  and  XML  source  code  for  the  DBF  articulation 
protocol. 

B.  DBF  ARTICULATION  JAVA  SOURCE  CODE 

package  org . npsnet . v . test . dabp . dbp foundation . dbputil; 

import  java.io.*; 
import  java.net.*; 
import  java . util .* ; 
import  java . util .Vector .* ; 
import  javax . vecmath . *; 
import  javax .media . j 3d .* ; 
import  java . lang . * ; 

import  org . npsnet . V . sys .* ; 
import  org . npsnet . V . net .* ; 

import  org . npsnet . v . test . dabp . dbpfoundation . *; 
import  org . web3d. vrtp . dabp .* ; 
import  org . web3d. vrtp . datatypes . * ; 

!  -k  -k 

*  A  protocol  for  transmitting  information  about  the  joint  positions 

*  in  articulated  entities.  Each  joint  uses  one  protocol! 

* 

*  @author  Bill  Fischer 
*/ 

public  class  DBPArticulationProtocol  extends  org . npsnet . v . sys . Protocol 
implements  Serializable 
{ 

j  k  k 

*  The  class's  version  string. 

*/ 

private  static  final  String  classVersion  =  "$Revision:  1.2  $ " ; 

I  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  classCodebaseString  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 

*  The  singleton  instance  of  this  class. 

*/ 

private  static  DBPArticulationProtocol  articulationProtocol; 

j  k  k 

*  The  known  location  of  this  class. 

*/ 

private  static  final  String  PROTO_URL  = 

"http : //homer . cs . nps . navy.mil/remote/" ; 

j  k  k 
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*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  hiXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/ArticulationProtocolPacket . xml " 

) ; 

^  -k  -k 

*  The  URL  to  the  XML  file  describing  the  High  Resolution  packet 

layout 

*/ 

String  loXmlFile  =  new 

String ( "c : / npsnetV/ org/npsnet/v/ test /dabp/ArticulationProtocolPacketLoRes 
. xml "  )  ; 


^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  hiResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (hiXmlFile)  ; 

^  -k  -k 

*  DABP  protocols  for  high  resolution 
*/ 

private  org . web3d . vrtp . dabp . Protocol  loResDabpProtocol  =  new 
org . web3d. vrtp . dabp .Protocol (loXmlFile)  ; 

^  -k  -k 

*  The  index  number  of  the  joint  this  protocol  is  for 
*/ 

private  int  jointNumber  =  0; 

^  -k  -k 

*  Returns  this  class's  version  string. 

*/ 

public  String  getClassVersion ( )  { 

return  classVersion; 

} 


^  -k  -k 

*  Returns  this  class's  codebase. 

*/ 

public  URL  getClassCodebase ( )  { 

try  {  return  new  URL (classCodebaseString)  ;  } 

catch (MalformedURLException  e)  {  return  null;  } 

} 


*  Returns  the  singleton  instance  of 
<code>ArticulationProtocol</code> . 

*/ 

public  static  DBPArticulationProtocol  getinstance ( )  { 

if (articulationProtocol ! =null)  return  articulationProtocol; 
else  { 

try  { 

org . npsnet . V . sys . Protocol  tmpProt  = 

get Singlet on ( "org . npsnet . v . test . dabp . dbp foundation . dbputil . DBPArticulatio 
nProto  col" , classVersion) ; 

if (tmpProt  ==  null) 

articulationProtocol  =  new  DBPArticulationProtocol () ; 

else 
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articulationProtocol  = 
(DBPArticulationProtocol) tmpProt ; 

} 

catch ( IDServerException  ise)  { 
System. out .println (ise) ; 
System . exit ( 1 ) ; 

} 


return 


articulationProtocol; 


^  -k  -k 

*  Constructor;  takes  a  few  parameters,  which  allow  us 

*  to  operate  in  the  world. <p> 

•k 

*  Note  that  this  constructor  is  for  use  with  new  EntityMasters — 

*  We  create  a  new  entity  and  send  out  information  on  it.  The 

*  creation  of  the  entity  registers  a  new  entity  ID  and  new 

protocolIDs 

*  to  go  along  with  it.<p> 

•k 

*  @param  pEntity  entity  that  we  update 
*/ 

public  DBPArticulationProtocol ( )  throws  IDServerException 

{ 

//  A  new  instance  requires  a  new  ID 

super ( "dbpArticulationProtocol" ,  true) ; 

} 


^  -k  -k 

*  constructor.  Note  that  this  constructor  is  for  use  with 

*  things  we  have  discovered  from  the  net.  we  get  in  a  new 

*  message  with  an  existing  ID.  That  means  we  don't  have  to 

*  look  up  the  ID  on  the  IDServer.<p> 

•k 

*  @param  pID  id  of  the  protocol,  gleaned  from  network  traffic 
*/ 

public  DBF ArticulationProtocol (long  pID)  throws  IDServerException 

{ 

super (pID,  IDCache . getIDCache ( ) . getNameForlD (pID) ) ; 

} 


^  k  k 

*  This  receives  a  packet  from  the  entity  and  serializes  it,  ie, 

changes 

*  all  the  data  fields  into  a  byte  array  that  we  can  send  across  the 

*  network.  ADU  is  some  nominal  superclass  from  DABP  that  subsumes  all 

*  packets. 

*/ 

public  byte[]  serializeADU (Object  pPacketData) 

{ 


byte  serializedData [ ]  =  null; 

ADUData  articulationADU  =  null; 

articulationADU  =  (ADUData) pPacketData; 

ByteArrayOutputStream  oStream  =  new  ByteArrayOutputStream ( ) ; 
DataOutputStream  dos  =  new  DataOutputStream (oStream) ; 


articulationADU. serialize (dos)  ; 
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serializedData  =  oStream . toByteArray ( ) ; 


return  serializedData; 

} 


^  -k  -k 

*  Receives  a  packet  from  the  EntityDispatcher  (or  whatever.)  The 

*  data  we  get  in  is  just  an  array  of  bytes — we  have  to  interpret 

those 

*  bytes  so  that  we  can  do  something  with  them.  This  consists  of  two 

*  things :  determing  syntax,  so  we  can  retrieve  the  field  named 

*  "position . x" ;  and  determining  semantics,  so  we  know  that 

position . X 

*  refers  to  the  location  of  the  entity  in  3-space.  We  instantiate 

*  an  ADUData  packet,  lay  it  out  in  the  format  described  by  the 

*  protocol's  XML  document,  and  fill  in  the  packet's  fields  from  the 

*  incoming  byte  stream  data. 

*/ 

public  void  receivePacket (byte [ ]  pData,  NetworkAware  entity) 

{ 

ByteArraylnputStream  bais  =  new  ByteArrayInputStream (pData) ; 

//  Temporary  workaround;  prevents  EntityMasters  from  being 
//  modified  remotely 

if (entity  instanceof  EntityMaster )  return; 
if (entity  instanceof  DBPArticulatedMaster )  return; 

//We  only  get  packets  of  one  type,  so  we  don't  need  to  check 
//  on  format  beforehand  (famous  last  words) . 

ADUData  packet  =  null; 

packet  =  hiResDabpProtocol . binaryDataToADU (pData) ;  //binaryDataToADU 

//  some  temporary  objects  &  variables 
Quat4d  jointOrientations  =  null; 


try 

{ 

if (  ( (UnsignedByte) (packet . get ( "markerValue" ))) .byteValue ( )  ==  95) 

{ 


if (( (UnsignedByte) (packet . get ( "packetResolution . resolution" )) ) . byteValue ( )  == 
1) 

{  packet  =  loResDabpProtocol .binaryDataToADU (pData) ; 

/ /binaryDataToADU 

}//  end  if 


//  some  temporary  variables 
double  jox,  joy,  joz,  jow; 


the 


//  fill  the  blank  ADUData  packet  with  the  corresponding  fields  from 
//  incoming  byte  stream 


jox  = 

(double) ( ( (PrimitiveNumber) packet . get ( "orientation . orl " ) ) . doubleValue ( ) ) ; 
joy  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "orientation . or2 " ) ) . doubleValue ( ) ) ; 
joz  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "orientation . or3 ") ) . doubleValue ( ) ) ; 
jow  = 

(double) ( ( (PrimitiveNumber ) packet . get ( "orientation . or4 " ) ) . doubleValue ( ) ) ; 
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jointOrientations  =  new  Quat4d(jox,  joy,  joz,  jow) ; 

//  System . out .println ( "Receive  side  — 

Transf ormProtocol : receivePacket (): packet  ==  "+  packet); 

( (DBP Articulated) entity)  . set JointOrientation ( jointNumber , 
jointOrientations) ; 

}//  end  if 
else 

{  System. err . println ( "Wrong  marker  type  (not  99)"); 

}//  end  else 

} / /  end  try 

catch (FieldNotFoundException  fnfe) 

{ 

System . err .println ( "Field  not  found!  "  +  fnfe); 

}//  end  catch 

return; 

} 


^  -k  -k 

*  Invoked  when  an  entity  is  modified.  The  entity's  articulation 

information 

*  is  loaded  into  an  ADUData  packet,  which  is  then  serialized  and 

passed 

*  to  the  Entity  Master. 

*/ 

public  void  entityChanged (Entity  e.  Object  info) 

{ 

if (e  instanceof  DBPArticulatedGhost)  return; 

ADUData  articulationADU  =  null; 
articulationADU  =  new  ADUData (new 
ADU (hiResDabpProtocol . getSchemaNamed ( "ARPPPDU" ) ) )  ; 

if (resolution  ==  1) 

{  articulationADU  =  new  ADUData (new 
ADU (loResDabpProtocol . getSchemaNamed ( "ARPPPDU" )  )  )  ; 

} 

//  orientation 

double [ ]  jointOpsArray  =  new  double [ 4]; 

Quat4d  jointOps  =  new  Quat4d(); 

( (DBPArticulated) e) . getUointOrientation ( jointOps,  jointNumber) ; 
jointOps. get (jointOpsArray) ; 

double  jox  =  jointOpsArray [ 0 ] ; 
double  joy  =  jointOpsArray [ 1 ] ; 
double  joz  =  jointOpsArray [2 ] ; 
double  jow  =  jointOpsArray [3] ; 

try 

{ 

//  load  the  ADUData  packet 

articulationADU . put ( "packet Re solution . resolution" ,  new 
UnsignedByte (resolution) )  ; 

String  tempString  =  new  String (" jointOrientations . x" )  ; 
if (articulationADU . get (tempString)  instanceof  DoublePrecision) 
articulationADU . put (tempString,  new  DoublePrecision (jox)); 
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else  if (articulationADU . get (tempString)  instanceof 
Single? reels ion) 

articulationADU . put (tempString,  new 
SinglePrecision ( (float) jox) ) ; 

tempString  =  new  String (" jointOrientations . y" ) ; 

if (articulationADU . get (tempString)  instanceof  DoublePrecision) 
articulationADU . put (tempString,  new  DoublePrecision ( joy) ) ; 

else  if (articulationADU . get (tempString)  instanceof 
SinglePrecision) 

articulationADU . put (tempString,  new 
SinglePrecision ( (float) joy) ) ; 

tempString  =  new  String  (" jointOrientations . z ") ; 

if  (articulationADU . get (tempString)  instanceof  DoublePrecision) 
articulationADU . put (tempString,  new  DoublePrecision ( joz) ) ; 

else  if (articulationADU . get (tempString)  instanceof 
SinglePrecision) 

articulationADU . put (tempString,  new 
SinglePrecision ( (float) joz) ) ; 

tempString  =  new  String (" jointOrientations . w" ) ; 

if (articulationADU . get (tempString)  instanceof  DoublePrecision) 
articulationADU . put (tempString,  new  DoublePrecision ( jow) ) ; 

else  if (articulationADU . get (tempString)  instanceof 
SinglePrecision) 

articulationADU . put (tempString,  new 
SinglePrecision ( (float) jow) ) ; 

}//  end  try 

catch (FieldTypeException  fte) 

{ 

System . err .println ( "Field  Type  not  found:  "  +  fte); 

}//  end  catch 

catch (FieldNotFoundException  fnfe) 

{ 

System . err .println ( "Field  not  found:  "  +  fnfe); 

}//  end  catch 


//  System . out .println (" Send  side  - 

ArticulationProtocol : entityChanged (): articulationADU  ==  \n"  + 
articulationADU) ;//*************888888888888888888 

//  Serialize  and  send  articulation  data  for  the  entity 

byte [ ]  data  =  serializeADU (articulationADU) ; 

Set  distroSet  =  AOIM. getAOIM ( ) . getDistributionSet (e,  this); 

EntityDispatcher . getEntityDispatcher  ( )  . sendPacket (this , 

e . getID ( ) , 
distroSet, 
data) ; 

} 


^  -k  -k 

*  Sets  the  joint  number  that  this  protocol  is  for 
*/ 

public  void  set JointNumber (int  pJoint) 

{  jointNumber  =  pJoint; 

}//  end  setUointNumber ( ) 

^  k  k 
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*  Gets  the  joint  number  that  this  protocol  is  for 
*/ 

public  int  get JointNumber ( ) 

{  return  jointNumber; 

}//  end  get JointNumber ( ) 


C.  DBP  ARTICULATION  HIGH  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="ARTICULATION_STATE" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
cl lent St ub=" http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . DoubleP reels ion" 

value=" f lie : //org . web3d. vrtp . datatypes . DoublePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f lie : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f lie : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<! —  <Channel  multicastAddress="225 . 7 . 8 . 30" 

multicastPort  =  "4070"  />  — > 

<Channel  multicastAddress="225 .8.7. 1222 " 
multicastPort  =  "2020"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

< /Packet Header > 

<ADU  name="ARPPPDU"  markerValue=" 95"> 

<! —  <Field  name="markerValue" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 95" />  — > 

<Structure  name= " packet Res oluti on "> 

<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue="2"/> 

</ Structure> 

<Structure  name=" jointOrientations"> 

<Field  name="x" 
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tYpe="org . web3d . vrtp . datatypes . DoubleP reels ion" 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="w" 

type="org . web3d . vrtp . datatypes . DoublePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 


D.  DBP  ARTICULATION  LOW  RESOLUTION  SOURCE  DOCUMENT 

<?xml  version=" 1 . 0 " ?> 

<!DOCTYPE  Protocol  SYSTEM  " . /DynamicBehaviorProtocol . dtd" > 

<Protocol  name="ARTICULATION_STATE" 
markerPosition=" 0 " 

markerType="org . web3d. vrtp . datatypes . UnsignedByte" 
clientStub="http : //some . url . com/baz "> 

<Type  name="org . web3d . vrtp . datatypes . SingleP reels ion" 

value=" f ile : //org . web3d. vrtp . datatypes . SinglePrecision"></Type> 

<Type  name="org . web3d . vrtp . datatypes . UnsignedByte" 

value=" f ile : //org . web3d. vrtp . datatypes . UnsignedByte"></Type> 

<Type  name="org . web3d . vrtp . datatypes . Signedinteger " 

value=" f ile : //org . web3d. vrtp . datatypes . Signedinteger "></Type> 

<! —  <Channel  multicastAddress="225 . 7 . 8 . 30" 

multicastPort  =  "4070"  />  — > 

<Channel  multicastAddress="225 .8.7. 1222 " 
multicastPort  =  "2020"  /> 

<PacketHeader  name="RTP"> 

<Field  name="sequence" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 

<Field  name="timestamp" 

type="org . web3d. vrtp . datatypes . Signedinteger" 
initialValue=" 0 " /> 


< /Packet Header > 

<ADU  name="ARPPPDU"  markerValue=" 95"> 


<! —  <Field  name="markerValue 
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type="org . web3d. vrtp . datatypes . UnsignedByte 
initialValue=" 95" />  — > 


<Structure  name= " packet Resolut i on "> 

<Field  name="resolution" 

type="org . web3d. vrtp . datatypes . UnsignedByte" 
initialValue=" 1 " /> 

</ Structure> 

<Structure  name=" jointOrientations "> 

<Field  name="x" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="y" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="z" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

<Field  name="w" 

type="org . web3d . vrtp . datatypes . SinglePrecision" 
initialValue=" 0 . 0 " /> 

</ Structure> 

</ADU> 

</Protocol> 


E.  SUMMARY 

The  source  code  and  source  documents  presented  in  this  appendix  work  together 
to  provide  both  a  high  and  low  resolution  capabihty  for  the  DBP  articulation  protocol. 
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APPENDIX  F 


A.  INTRODUCTION 

This  appendix  shows  how  to  produce  an  XML  source  document  for  an  example 
dynamic  protocol  created  using  an  X3D  Edit  DBF  Protocol  editor. 

B.  DBF  PROTOCOL  EDITOR 

An  XML  editor  for  DBP  patterned  after  X3D  Edit  (Web  3D  Consortium,  01), 
authored  by  Don  Bmtzman,  can  be  used  to  generate  DBP  protocols  for  use  in  NPSNET- 
V.  This  DBP-Edit  editor  enables  a  user  to  create  protocols  using  a  symbohc  GUI 
interface,  rather  than  requiring  the  tedium  of  typing  the  protocols. 


Figure  F.l  DBP  profile  editor  to  modify  tooltips  for  elements  and  attributes 
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Figure  F.2  DBF- Edit  interface 

C.  DBF  DATA-TYPE  DEFINITION  (DTD) 


<?xml  version=" 1 . 0 "  encoding="UTF-8 " ?> 

<! —  A  dtd  for  a  flexible  protocol  description  language  — > 

> 
> 
> 

<!ELEMENT  Protocol  ((Type!),  Channel,  (PacketHeader?) ,  (ADU+))> 


<! —  Author:  Don  McGregor  — > 

<!—  Date:  3/13/2000— > 

<  I - > 

<! —  The  protocol  tag  encloses  some  descriptions  about  the  protocol — 
<! —  itself,  followed  by  the  ADUs  in  the  protocol.  The  +  sign  means — 
<! —  one  or  more,  the  ?  means  zero  or  one.  — 


120 


— > 


<! —  Attributes: 
<!  — 

for  the  field  — > 

<!  — 

ADUs  in  the  — > 

<!  — 

< !  — 

between  ADUs .  — > 

<!  — 

byte,  short  — > 

<!  — 

< !  — 

semantics.  — > 


name:  The  name  of  the  protocol  (dis,  etc.) 
markerPosition :  the  number  of  bytes  to  offset  to  look 

that  distinguishes  between  different 

protocol.  — > 

markerType :  The  type  of  the  data  that  distinguishes 

This  must  be  one  of  the  listed  Types  below. 

int,  etc.  — > 

clientStub:  The  stub  program  we  use  to  tie  syntax  to 


<!ATTLIST  Protocol  name  CDATA  #REQUIRED 

markerPosition  CDATA  #REQUIRED 

markerType  CDATA  #REQUIRED 

clientStub  CDATA  #IMPLIED> 

<! —  A  type  is  just  a  string  that  describes  a  URL.  The  thing  at  that 
location  — > 

<! —  has  code  for  defining  the  type  of  data.  These  are  the  basic  building 
blocks  — > 

<! —  of  the  protocol;  how  we  bootstrap  up  an  initial  set  of  basic  types, 
like  — > 

<! —  int,  short,  double,  etc.  — > 

< ! ELEMENT  Type  EMPTY> 

<! —  Attributes:  The  type  name  is  an  ID,  which  means  it  can  be  referenced 

— > 

<! —  elsewhere  in  the  XML  file.  — > 


<!ATTLIST  Type  name  ID  tREQUIRED 

value  CDATA  #REQUIRED> 

<! —  A  MulticastGroup  is  just  an  element  that  can  hold  things  like 
multicast  — > 

<! —  port,  etc  — > 

<! ELEMENT  Channel  EMPTY  > 

<! —  Attributes:  address:  mcast  address  used  by  this  protocol.  — > 

<! —  port:  mcast  port  to  listen  to  for  packets  — > 

<!ATTLIST  Channel  multicastAddress  CDATA  tREQUIRED 

multicastPort  CDATA  tREQUIRED 

serverAddress  CDATA  tIMPLIED 

serverPort  CDATA  tIMPLIED> 

<! —  An  ADU  contains  tags  for  various  types  of  fields.  The  ADU  tag  must 
contain  — > 

<! —  at  least  one  field  tag  -  a  field,  structure.  Array,  or  List.  — > 


<!ELEMENT  ADU  ((Field  |  Structure  I  Array  I  List)+)> 

<!ATTLIST  ADU  name  CDATA  tREQUIRED 

markerValue  CDATA  tREQUIRED> 

<! —  Field  types,  which  are  slightly  tricky.  There  are  four  basic  types 
of  — > 

<! —  fields:  a  primitive  type,  which  describes  something  like  a  byte 

— > 
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<! —  or  a  float;  a  structured  type,  which  can  contain  a  several  primitive 
types; — > 

<! —  an  array,  which  has  a  fixed  length  repetition  of  Field  or  Structure; 

— > 

<! —  and  a  List,  which  has  a  variable  length  (per-packet)  number  or 
repeitions  — > 

<! —  of  a  Field  or  a  Structure. — > 

<! —  The  basic  Field  type,  which  describes  one  of  the  Types  listed  above. 

— > 

<! —  This  is  an  empty  tag  -  all  the  information  is  contained  in  the  tag 
and  — > 

<! —  its  attributes,  not  in  anything  the  start  and  end  tags  surround.  In 

— > 

<! —  fact,  you  can't  have  anything  between  the  tags  -  it's  required  to  be 

— > 

<! —  be  empty,  usually  done  with  <Field  name="foo"  type="byte" 
initialValue=" 0 " />  — > 

<! ELEMENT  Eield  EMPTY> 

<! —  Attributes:  name:  Name  for  the  field,  such  as  "x"  or  "speed" 

— > 

<! —  type:  basic  datatype,  must  be  from  Type  list  above 

— > 

<! —  initialValue :  Default  value  for  field  ,  such  as  "0"  or 

"17".  — > 

<!ATTLIST  Eield  name  CDATA  #REQUIRED 
type  IDREE  #REQUIRED 
initialValue  CDATA  #REQUIRED> 

<! —  The  Structure  tag  defines  an  enclosing  container  for  other  fields. 
This  — > 

<! —  lets  us  build  up  larger  constructs,  such  as  "Point"  that  contains 
three  — > 

<! —  Eields,  (x,y,z) .  or  we  could  have  a  Strucutre  that  contains  a 
mixture  — > 

<! —  of  Fields,  lists,  and  other  structures.  — > 

<! ELEMENT  Structure  ((Eield  |  List  |  Array  |  Structure) +)  > 

<! —  Attributes:  name:  the  name  of  the  structure.  — > 

<!ATTLIST  Structure  name  CDATA  #REQUIRED> 

<! —  Information  about  the  PacketHeader .  This  is  intended  to  describe, 
for  — > 

<! —  example,  the  RTP  header  for  a  packet.  This  is  prepended  to  every 
outgoing  — > 

<! —  payload,  and  used  for  routing,  etc.  This  is  really  just  an  ADU 
undercover  — > 

<! —  The  Array  tag  must  contain  either  ONE  Eield  tag  or  ONE  Structure 
tag.  — > 

<! —  This  piece  of  data  is  repeated  some  number  of  times.  Under  Array, 

— > 

<! —  this  is  a  number  that  does  not  change,  ever.  If  you  say  it  has  five 

— > 

<! —  elements,  it  will  always  have  space  for  five  elements. 

— > 
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<! —  The  Array,  which  is  always  some  parse-time  defined  length. 


<! ELEMENT  Array  (Eield  |  Structure) > 


<! —  Attributes:  name:  Name  of  array  — > 

<! —  size:  Number  of  times  the  element  contained  repeats. 


— > 

the 


<!  — 

— > 

<!  — 

<!ATTLIST  Array 


must  always  be  the  same;  cannot  change  after 

document  is  parsed.  — > 

name  CDATA  tREQUTRED 
size  CDATA  #REQUTRED> 


— > 


Field 


tells- 


<! —  The  List  element  has  a  variable  length,  which  may  change  from  paclcet 

<! —  to  packet.  The  length  of  the  list  is  defined  in  some  other  field  in 

<! —  the  payload.  We  save  a  reference  to  that  field  as  an  attribute;  at 

<! —  runtime,  we  lookup  the  value  of  the  field  to  determine  how  long  the 

<! —  list  will  be  in  this  instance.  A  List  repeats  either  a  primitive 
— > 

<! —  or  a  Structure  zero  or  more  times.  — > 

<! ELEMENT  List  (Field  I  Structure) > 

<! —  Attributes:  Name:  Name  of  the  list  — > 

<! —  lengthFieldName :  name  of  the  field  in  this  payload  that 

-> 

<! —  us  how  long  this  list  is.  — > 

<!ATTLIST  List  name  CDATA  #REQUIRED 

lengthFieldName  CDATA  #REQUIRED> 

<!ELEMENT  PacketHeader  ((Field  |  Structure  |  Array  |  List)+)> 

<! —  Attributes:  name:  name  of  the  packet  header,  eg  ' rtp ' .  — > 

<!ATTLIST  PacketHeader  name  CDATA  #IMPLIED> 


D.  DBP  PROFILE 


<?xml  version=" 1 . 0 "  encoding="UTF-8 " ?> 

<!DOCTYPE  DTDProfile  SYSTEM  "prof ile . dtd" > 

<DTDProfile  title="DynamicBehaviorProtocol . dtd  Editor"> 

<defaults  encoding="UTF-8 " 
systemLiteral="DynamicBehaviorProtocol . dtd" /> 

<elements> 

<element  name="ADU"  tooltip="contains 

(Field  I  Structure  I  Array  I  List ) +&#10 ; Application  Data  Unit  (ADU)  definition . "> 
<attribute  editor="TextField"  name="name"  tooltip="name  CDATA 

tREQUTRED" /> 

<attribute  editor="TextField"  name="markerValue" 
tooltip="markerValue  CDATA  #REQUIRED"/> 

</element> 

<element  name="Array"  tooltip="contains  (Field I  Structure) &#10 ; defines 
an  Array  of  Fields  or  Structures"> 
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Ottribute  editor="TextField"  name="name"  tooltip="name  CDATA 

#REQUIRED"/> 

<attribute  editor="TextEield"  name="size"  tooltip="size  CDATA 

#REQUIRED"/> 

</element> 

<element  name=" Channel"  tooltip="EMPTY&#10; Defines  multicast  channel 
parameters "> 

<attribute  editor="TextEield"  name="multicastAddress " 
tooltip="multicastAddress  CDATA  #REQUIRED"/> 

<attribute  editor="TextEield"  name="multicastPort " 
tooltip="multicastPort  CDATA  #REQUIRED"/> 

<attribute  editor="TextEield"  name="serverAddress" 
tooltip="serverAddress  CDATA  #IMPLIED"/> 

<attribute  editor="TextEield"  name="serverPort"  tooltip=" serverPort 
CDATA  #IMPLIED"/> 

</element> 

<element  name="Eield"  tooltip="EMPTY&#10 ; Defines  a  Field  data 

structure"> 

<attribute  editor="TextField"  name="name"  tooltip="name  CDATA 

#REQUIRED"/> 

<attribute  editor="TextField"  name="type"  tooltip="type  IDREF 

#REQUIRED"/> 

<attribute  editor="TextField"  name="initialValue" 
tooltip="initialValue  CDATA  #REQUIRED"/> 

</element> 

<element  name="List"  tooltip="contains  (Field | Structure) &#10; Defines 
a  list  of  Fields  or  Structures"> 

<attribute  editor="TextField"  name="name"  tooltip="name  CDATA 

#REQUIRED"/> 

<attribute  editor="TextField"  name="lengthFieldName" 
tooltip="lengthFieldName  CDATA  #REQUIRED"/> 

</element> 

<element  name="PacketHeader "  tooltip="contains 
(Field  I  Structure | Array | List )+& #10 ; defines  Packet Header  contents "> 

<attribute  editor="TextField"  name="name"  tooltip="name  CDATA 

#IMPLIED"/> 

</element> 

<element  name="Protocol"  tooltip="contains 
(Type+, Channel, PacketHeader? , ADU+) &#10; Root  element  to  define  a  Dynamic 
Behavior  Protocol. "> 

<attribute  editor="TextField"  name="name"  tooltip="name  CDATA 

#REQUIRED"/> 

<attribute  editor="TextField"  name="markerPosition" 
tooltip="markerPosition  CDATA  #REQUIRED"/> 

<attribute  editor="TextField"  name="markerType"  tooltip="markerType 
CDATA  #REQUIRED"/> 

<attribute  editor="TextField"  name="clientStub"  tooltip="clientStub 
CDATA  #IMPLIED"/> 

</element> 

<element  name="Structure"  tooltip="contains 
(Field  I  List  I  Array  I  Structure) +&#10 ; defines  a  data  Structure"> 

<attribute  editor="TextField"  name="name"  tooltip="name  CDATA 

#REQUIRED"/> 

</element> 

<element  name="Type"  tooltip="EMPTY&#10; defines  a  payload  data 
structure  type"> 

<attribute  editor="TextField"  name="name"  tooltip="name  ID 

#REQUIRED"/> 

<attribute  editor="TextField"  name="value"  tooltip="value  CDATA 

#REQUIRED"/> 

</element> 

<element  name="XML_COMMENT"  tooltip=" Comment  -&#10;Use  it  anywhere  to 
make  the  document  clearer. "/> 
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<element  name="XML_TEXT"  tooltip="TEXT"/> 

<element  name="XML_CDATA"  tooltip="CDATA  Section  -&#10;Use  it  to 
store  marked-up  text  that  you  want  to  store  as  data."/> 

<element  name="XML_PI "  tooltip="Processing  Instruction  (PI)  -&#10;Use 
it  to  pass  directions  and  information  to  programs. "/> 

<element  name="XML_DOCUMENT_TYPE"  tooltip="Document  Type."/> 
</elements> 

<documents/> 

<palettes> 

<toolbarpalette  title="Standard"> 

<group  elements="XML_TEXT  XML_CDATA  XML_COMMENT  XML_PI 
XML_DOCUMENT_TYPE"  /> 

</toolbarpalette> 

<sidebarpalette  all-visible="no"  searchable="no"  title="Elements"> 
<group  elements="ADU  Array  Channel  Field  List  PacketHeader  Protocol 
Structure  Type"/> 

</sidebarpalette> 

<sidebarpalette  all-visible="yes "  searchable="no"  title="All 

Elements "> 

<group  elements="ADU  Array  Channel  Field  List  PacketHeader  Protocol 
Structure  Type"/> 

</sidebarpalette> 

</palettes> 

<importers/> 

<exporters/> 

<tools> 

<tool  class-name="com. ibm. hrl . xmleditor . extension . xsl . XSLHandler " /> 
</tools> 

</DTDProf ile> 


E.  SUMMARY 

The  documents  presented  in  this  appendix  provide  a  DBF  protocol  editor  that  uses 
X3D  Edit  to  generate  protocols  in  XML,  and  an  example  dynamic  protocol  for  use  in 
NPSNET-V. 
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